On Fri, Oct 19, 2007 at 01:35:25PM +0100, Richard W.M. Jones wrote: > >>See previous discussion about capabilities, also a hack: > >>https://www.redhat.com/archives/libvir-list/2007-March/msg00104.html > > > >The use of XML for describing metadata about managed objects is a core > >aspect of libvirt. We can debate use of XML vs structures for hours on > >end, but the fact remains that libvirt uses XML for its metadata APIs. > > XML is used in a few places: As a way to describe domains (in & out) and > for capabilities (out). The original capabilities proposal didn't use > XML -- I'm not proud that I folded on that one. > virConnectGetCapabilities returns sprawling XML that differs in ways we > don't really understand between hypervisors. We have avoided defining > real meanings to much of the capabilities XML. This is not a good > example to follow. > > If this is going to be decided by some sort of popularity contest > (`libvirt uses XML already so why not use a bit more'), then how about > we look at other comparable C libraries. How many of them return XML > from API calls, that is when they're not returning HTML documents or the > like? IMHO, consistent style to our APIs is important. As you say we already use XML for describing domains, virtual networks, and capabilities. Introducing a different approach just for describing storage just does not make sense to me at all, thus I want storage to be described using XML in the immediate implementation. That said I do recognise that there are some benefits to having APIs that operate in terms of statically typed structures. I am open to discussing how we could introduce new APIs equivalent to the existing create & dumpxml APIs - for *all* objects we represent. I think this should be a effort that is separate / in parallel with the addition of storage management APIs so we don't block implementation of the storage. If we look at the QEMU driver we already have structs to hold the working representation of a domain and a network. The 'test' driver also has its own structs. With some appropriate adjustments we could potentially make the QEMU structs generic enough that we'd be able to expose them via the public API. This could open up some interesting possibilities for reducing the amount of code in the internal drivers. Current we have - XM config -> XML parser - XML -> XM config parser - SEXPR -> XML parser - XML -> SEXPR parser - qemu struct -> XML formatter - XML -> qemu struct parser - test struct -> XML formatter - XML -> test struct parser As a first step, we could switch to using the 'qemu' structs inside all the drivers as the working representations. This would result in a single parser and single formatter across all drivers. We'd then just need to do a SEXPR to struct convertor & XM config to struct convertor. Once the internals were unified, we'd have a higher degree of confidience that our struct design was sufficiently flexible for all drivers. Though it would be nice to have one virt backend which wasn't styled on the QEMU device model - VMWare potentially hsa a quite different set of metadata. Anyway, if we had the internals all unified on a single struct design, then we could make the next step & expose virDomainCreateStruct(virDomainStructPtr) and virDomainStructPtr virDomainGetDescription() as equivalents for the existing virDomainCreate and virDOmainDumpXML methods - likewise for the storage, networking and capabilities APIs. Personally I'd like to do the unification of all the drivers to use the same structs internally anyway. I think it would result in more straight forward code & actually make it quicker & easier to write new backends. The vast majority of the work in backends is doing the XML parser and formatter. If we have a single intenral struct representation, adding a UserModeLinux driver could reuse nearly all of the QEMU driver code as is. All we would end is a new method to build up the ARGV for spawning the UML kernels. Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=| -- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list