[virt-tools-list] [libosinfo 3/3] Utility function to retrieve device by property

[Zeeshan Ali (Khattak)]

On Thu, Jan 19, 2012 at 6:33 PM, Daniel P. Berrange <berrange at redhat.com> wrote:
> On Thu, Jan 19, 2012 at 05:17:30PM +0100, Christophe Fergeau wrote:
>> On Thu, Jan 19, 2012 at 06:09:15PM +0200, Zeeshan Ali (Khattak) wrote:
>> > On Thu, Jan 19, 2012 at 5:42 PM, Zeeshan Ali (Khattak)
>> > >>> >> +
>> > >>> >> +    if (osinfo_list_get_length(OSINFO_LIST(devices)) > 0)
>> > >>> >> +        ret = OSINFO_DEVICE (osinfo_list_get_nth(OSINFO_LIST(devices), 0));
>> > >>> >
>> > >>> > I think it would be better to return the full list and let the app decide whether
>> > >>> > it wants the first item in the list or more than that.
>> > >>>
>> > >>> I guess, we can provide another function 'get_devices_by_property'  as well..
>> > >>
>> > >> What kind of properties do we get? Does it really make sense to only return
>> > >> the first one and ignore the other results? I don't know what kind of
>> > >> results this function returns, so hardcoding in the library this kind of
>> > >> "arbitrarily pick one result, drop the rest" makes me uncomfortable.
>> > >
>> > > https://bugzilla.gnome.org/show_bug.cgi?id=668229
>> >
>> > To help you avoid reading Vala code, the usecase is of creating a new
>> > VM for a paritcular OS. The sensible thing to do would be to add only
>> > devices supported by that OS. It also would usually make sense to add
>> > only one device of a particular class/type not all. So IMHO there is
>> > good chances that this function will be useful to other apps as well.
>>
>> I'm not questioning the usefulness of the function you want to add (or a
>> variation on it), what I'm questioning is hardcoding the "let's only
>> keep the first device in the list" in the library, it feels cleaner to
>> return a list and let the application pick only the first device if it
>> wants to.
>
> I tend to view libosinfo as providing the "mechanism" not the "policy",
> so I'm inclined to say that this kind of API is better suited to the
> application code.
>
> In the future, I see space for a "libvirt-install" library which
> binds together  libvirt-gobject & libosinfo with a set of policy
> driven APIs for installing OS. As & when that library becomes a
> reality, we can leverage code currently in Boxes, or other similar
> apps. So there's no strong reason to push it all into libosinfo
> right now, if it is getting into the realms of policy driven APIs.

Understood! However get_devices_by_property() that I'm writing now
doesn't dictate any policy so that could go into libosinfo?

-- 
Regards,

Zeeshan Ali (Khattak)
FSF member#5124