Re: [Libvir] 1/4 Additions to the public API
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/
veillard(a)redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/