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. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
