[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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.



Red Hat Virtualization group http://redhat.com/virtualization/
Daniel Veillard      | virtualization library  http://libvirt.org/
veillard redhat com  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine  http://rpmfind.net/

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]