On Tue, Jul 31, 2012 at 05:38:31PM +0100, Daniel P. Berrange wrote: > On Tue, Jul 31, 2012 at 11:22:09AM +0800, Daniel Veillard wrote: > > > So do we have a consensus on this? The first version expose guest IP via > > > public struct, while this one returns an XML doc. Which one should we > > > prefer? > > > > It seems to me people suggesting either ways > > 1/ struct if we just return the IP adress[es] > > 2/ XML if we want to expand all the other informations about the > > interface > > > > At this point I would think we are not really in a good situation to > > extract and expose all the interface settings as seen from the guest > > and as Dan said it's more something to be done on the guest agent, > > that interface is a backup in the absence of agent or a way to bootstrap > > communication with the guest. I think v1 does this fine, though I would > > agree with Eric feedback on the API changes, I would also suggest -1 > > as being the error failure code for this API. > > Then later if we can get full client interfaces viewpoint, as seen from > > the guest (is there an API for this in VMWare, we ought to be able to do > > it for LXC) then providing a second extensible API returning an XML > > could be added, but I think the core API need now it be able to easilly > > extract the IP(s) of the guest, and XML while being more flexible for > > future use would get in the way. > > > > So my take would be to refine v1, and based on feedback of v1, > > availability of informations in various drivers, then provide an > > XML extensible version if there is a need and a good way to provide > > the full information set. > > I think I've already mentioned I had a preference for v1 struct approach. > If we did go for th v2 XML approach, then I'd want us to align with the > virInteface XML schema for reporting interface configuration, instead of > creating a new schema. > > FWIW, I don't think it would be the end of the world if we added a > struct based API now, and then *also* added a XML based API at a > later date (should it become required)
okay, we agree, Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ dan...@veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/ -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
