Re: [libvirt] [PATCH v2 0/8] Add ability to store notes with domains

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.