On Fri, Feb 22, 2008 at 09:37:24AM +0000, Richard W.M. Jones wrote: > [... Struct versus 3 arrays discussion snipped ...]
First I should state it's a cool idea, even if I reacted to the proposed API. I also agree to some extend with Mark, the on disk storage should probably go in the network description. But that's orthogonal to the API side :) > I think both representations have their merits, and DV's "3 arrays" > approach is much easier to marshal through the remote code, and > simpler to produce OCaml bindings for (no idea about Python). For python we will need manually generated bindings anyway to have something which looks nice from a python viewpoint, for example the list would be nicer exported as a dictionary based on the host names, and one or the other won't make it much different. > The reason for using the struct was to provide extensibility. The > dnsmasq "--dhcp-hostfiles" file format is much richer than merely > (hwaddr, ipaddr [, hostname]) triplets. For example it can include > lease times and client IDs[1]. Okay, then we probably need to abstract the notion of dhcp host but I would not expose the structure then (which was my main beef in the intial patch) let's keep the structure private and provide accessors and lookups in the library, then we will be able to extend. > The API calls I chose give us the opportunity to extend the structure > with new elements in future. But to do this you have to provide a > deallocator (because additional elements may need to be freed), and > flags on the Add call. Agreed, but if you provide deallocator, provide allocators too, and acessors. > If we agree that we won't / can't / don't want to extend this > structure, I'd be more than happy to use 3 arrays and lose the > deallocator. It will simplify the remote code considerably. Actually at the remote level we probably don't need to expose the informations in the exact same way as in the public API, do we ? The way things are exposed though the API opaque structure doesn't have to match exactly the way it's done at the driver level, and there we can shoot for the most convenient way (while trying to be portable if we extend the set of informations). > [1] See the dnsmasq manual page for the full details. I'm not > convinced that the format is even well-specified by that manpage so > probably at some point we'll need to look at the source code. heh Daniel -- Red Hat Virtualization group http://redhat.com/virtualization/ Daniel Veillard | virtualization library http://libvirt.org/ [EMAIL PROTECTED] | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
