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>
>
> 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.
--
Eric Blake eblake@xxxxxxxxxx +1-919-301-3266
Libvirt virtualization library http://libvirt.org
Attachment:
signature.asc
Description: OpenPGP digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list