[libvirt] new API to get list of *all* interfaces matching a MAC

[Daniel Veillard]

On Tue, Aug 25, 2009 at 03:10:10PM +0100, Daniel P. Berrange wrote:
> On Tue, Aug 25, 2009 at 04:04:44PM +0200, Daniel Veillard wrote:
> > On Tue, Aug 25, 2009 at 10:15:05AM +0100, Daniel P. Berrange wrote:
> > > On Mon, Aug 24, 2009 at 03:24:13PM -0400, Laine Stump wrote:
> > > > (This probably seems like overanalysis of a simple problem. That's what 
> > > > I'm best at ;-)
> > > > 
> > > > Due to oversight, the function virInterfaceLookupByMACString() can only 
> > > > return a single interface, but it's possible that a host may have more 
> > > > than one interface with the same MAC. Since the API had already been 
> > > > released by the time we realized this, the existing function will remain 
> > > > and a new one added that can return a list of interfaces. This new API 
> > > > will need to deal with the fact that the list length is effectively 
> > > > unbounded. I can see three ways of dealing with this, and want to learn 
> > > > which is preferred by others before spending time on the implementation.
> > > 
> > > I'm rather wondering why exactly we need another API. 
> > 
> >  Basically to be able to obsolete the broken one, and explain in the
> > documentation the function limitation and suggest using the new one.
> > Way simpler to explain than suggesting doing the full extract and leave
> > the user filter.
> 
> I don't buy that argument. We have a clear split between vir*Lookup*
> methods returning a single object, and vir*List* methods giving back
> multiple objects, which is consistent across all the APIs. I don't
> think we need to do a specialcase for network interfaces, for something
> that'll rarely be an issue in the real world. The existing behaviour
> is easy to understand & document & deal with from applicaton code as 
> it is.

  And I don't buy that argument of homogenety of interface because
precisely the interfaces while named similary have actually different
behaviour in the case of Interface. And it's way easier to deal with
suggesting to use the right API directly, than wait for user error which
as you said will occur infrequently but will require a change at the
application level.
  If virDomainLookupByName could miss some domains, I would definitely
try to fix with a proper API to replace. I think the fact it's about
Interface doesn't make that less the right thing to do.
  The goal of the API is making sure the apps will be fine, not making
sure it's simpler for the app developper. That's the reason why apis
like gethostbyname and similar gets deprecated. Interface based code in
apps is yet to be written, let's make sure it's written correctly.

Daniel

-- 
Daniel Veillard      | libxml Gnome XML XSLT toolkit  http://xmlsoft.org/
daniel at veillard.com  | Rpmfind RPM search engine http://rpmfind.net/
http://veillard.com/ | virtualization library  http://libvirt.org/