On Mon, Jan 23, 2012 at 09:46:57AM -0700, Eric Blake wrote:
On 01/23/2012 09:23 AM, Daniel P. Berrange wrote:
Changing <title> or <description> of a transient domain is a nice-to-have, but not the end of the world. Changing <metadata> of a transient domain is a must-have, so we need at least one new API. Setting is important, while getting is only a shortcut (we can make the user call virDomainGetXMLDesc, and do an XPath query), but symmetry is nice. Meanwhile, libvirt shouldn't care about the contents of <metadata>, other than that it is a well-formed XML string. We do _not_ need virTypedParams, but can stick with just an enum for which piece of metadata to be modifying. We can get by with just one API for all three elements, as well as leaving the door open for any future metadata. So
For the <metadata> element we want more tha njust a well-formed XML string. The intention is that every top level element inside <metadata> *must* declare its own private XML namespace. The default namespace is to be reserved for any libvirt official metadata elements we might introduce in the future.
Do we want to start out with <description> or even <title> as our first libvirt-official metadata (that is, in the spirit of backcompat, output:
<domain ...> <description>desc</description> <metadata> <description>desc</description> </metadata> </domain>
Nah, I feel that's just overkill - it is harmless having description and title outside the block IMHO.
While fine for title/description, I don't think this really works for <metadata>. When setting the metadata we'd want to specify an XML namespace key and URI, and when getting the metadata we'd really want to specify a namespace URI
Ah, so you're thinking of getting at an individual sub-element within <metadata>, where I was thinking of grabbing the entire <metadata> element and making the user sift through the sub-elements to the ones they want. Your proposal does indeed make a bit more sense, in saving the user some effort for filtering to just the metadata elements they care about, and when setting things, they can set just the ones they care about while leaving all other existing metadata elements untouched (instead of having to do a read-modify-write cycle). Your proposal also makes it easier to force the user to specify a namespace for each element that goes into metadata. But it also makes it sound like we are imposing one additional constraint on <metadata> - each subelement must be a distinct namespace, so you cannot have multiple top-level metadata elements from the same namespace.
That is correct - basically the top level element would be a container inside which all the app's metadata would live, so I'd expect apps todo <metadata> <virtman:guest xmlns:virtman="http://virt-manager.org/guets/1.0"> <ostype>linux</ostype> <osvariant>fedora16</osvariant> </virtman:guest> </metadata> And *not* <metadata> <virtman:ostype xmlns:virtman="http://virt-manager.org/guets/1.0">linux</virtman:ostype> <virtman:osvariant xmlns:virtman="http://virt-manager.org/guets/1.0">fedora16</virtman:osvariant> </metadata> Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|