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 :|
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list