[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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



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.

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]