Eric, could you please share your opinion as to what should be more appropriate to use for this functionality: Structs/XML/VirTypedParams ?
On Tue, Jul 2, 2013 at 7:25 PM, Osier Yang <jy...@redhat.com> wrote: > On 02/07/13 18:33, Daniel P. Berrange wrote: > >> On Fri, Jun 28, 2013 at 03:56:10PM +0530, Nehal J. Wani wrote: >> >>> Hello, fellow developers! >>> I am a GSoC candidate this year working for libvirt.org. My >>> project is "Introduce API to query IP addresses for given domain". >>> The discussion regarding this feature had started here: >>> http://www.mail-archive.com/**libvir-list@redhat.com/**msg51857.html<http://www.mail-archive.com/libvir-list@redhat.com/msg51857.html>and >>> then Michal had sent a patch too (refer: >>> http://www.mail-archive.com/**libvir-list@redhat.com/**msg57141.html<http://www.mail-archive.com/libvir-list@redhat.com/msg57141.html>). >>> But >>> it was not pushed upstream due to lack of extensibility. >>> >>> So far I've come up with an API and I want to get your opinion before >>> I start writing the rest so I don't follow the wrong direction. >>> >>> Following are the valid commands: >>> >>> domifaddr <domain-name> >>> domifaddr <domain-name> <interface-name> >>> domifaddr <domain-name> <interface-name> <method> >>> domifaddr <domain-name> <method> >>> >> What are valid values for '<method>' here ? >> >> methods: >>> (i) Querying qemu-guest-agent >>> (ii) Getting info from dnsmasq.leases file >>> (iii) Using the nwfilter to snoop the traffic >>> >>> If no method is mentioned, qemu-guest-agent will be used. >>> >>> Previous attempts by Michal had used structs and xml. Structs bring in >>> restrictions and xml has to be parsed. Hence I am not planning to >>> continue with either of these. >>> >>> As a start, I would like to know your comments about my API which >>> queries the qemu-guest-agent and returns the results in >>> virTypedParameter **params. >>> >>> Format(JSON) in which the qemu guest agent returns info: >>> >>> [{"name":"lo", >>> "ip-addresses": >>> [{"ip-address-type":"ipv4","**ip-address":"127.0.0.1","* >>> *prefix":8}, >>> {"ip-address-type":"ipv6","ip-** >>> address":"::1","prefix":128}], >>> "hardware-address":"00:00:00:**00:00:00"}, >>> {"name":"eth0", >>> "ip-addresses": >>> [{"ip-address-type":"ipv4","** >>> ip-address":"192.168.122.42","**prefix":24}, >>> {"ip-address-type":"ipv6","ip-** >>> address":"fe80::5054:ff:fe09:**d240","prefix":64}], >>> "hardware-address":"52:54:00:**09:d2:40"}] >>> >>> //Possible 1-D Structure (A little hassle to maintain) >>> >>> params[0] = {"iface-count",int,2} >>> params[1] = {"iface-name",string,"lo"} >>> params[2] = {"iface-hwaddr",string,"00:00:**00:00:00:00"} >>> params[3] = {"iface-addr-count",int,2} >>> params[4] = {"iface-addr-type",string,"**ipv4"} >>> params[5] = {"iface-addr",string,"127.0.0.**1"} >>> params[6] = {"iface-addr-prefix",int,8} >>> params[7] = {"iface-addr-type",string,"**ipv6"} >>> params[8] = {"iface-addr",string,"::1"} >>> params[9] = {"iface-addr-prefix",int,128} >>> .... >>> .... >>> .... >>> >>> //2D Structure: (Not very hasslefree, but easier to maintain as one >>> interface per row) >>> >>> params[0] = {"iface-name",string,"lo"}{"**iface-hwaddr",string,"00:00:** >>> 00:00:00:00"}{"iface-addr-**type",string,"ipv4"}{"iface-** >>> addr",string,"127.0.0.1"}{"**iface-addr-prefix",int,8}{"** >>> iface-addr-type",string,"ipv6"**}{"iface-addr",string,"::1"}{"** >>> iface-addr-prefix",int,128} >>> params[1] = {"iface-name",string,"eth0"}{"**iface-hwaddr",string,"52:54: >>> **00:09:d2:40"}{"iface-addr-**type",string,"ipv4"}{"iface-** >>> addr",string,"192.168.122.42"}**{"iface-addr-prefix",int,8}{"** >>> iface-addr-type",string,"ipv6"**}{"iface-addr",string,"fe80::** >>> 5054:ff:fe09:d240"}{"iface-**addr-prefix",int,64} >>> >> IMHO both of these approaches to encoding the data in virTypedParameter >> are seriously unpleasant for an app to deal with. Now this is a true for >> virTypedParameter in general, but I think that the need to deal with a >> list of objects here, each containing a list of typed parameters makes >> it even worse than normal. I wouldn't really like this as an application >> developer. >> >> Looking at this possible approach of virTypedParameter, I'm think I am >> preferring either the XML or fixed struct approach to this API as was >> proposed in the past, with a bias towards a fixed struct for simplicity >> of use by app developers. >> > > agreed. > > after seeing the trouble caused by multiple addrs, i'm not sure about > using virTypedParameter too. even if we have an array type value, it still > looks like not easy to use for api user, one has to know how many elements > of the array too. > > > >> >> Regards, >> Danuiel >> > > -- Nehal J. Wani UG2, BTech CS+MS(CL) IIIT-Hyderabad http://commandlinewani.blogspot.com
-- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list