On Wed, Sep 30, 2009 at 03:49:05PM +0200, Matthias Bolte wrote: > 2009/9/30 Daniel Veillard <veillard@xxxxxxxxxx>: > > https://bugzilla.redhat.com/show_bug.cgi?id=523639 > > > > feature request which makes sense to me, the simple patch attached > > seems to be sufficient, one can define and have the description back > > in the dump. Doesn't try to keep the location of the tag, it always > > get serialized after <uuid>. > > The only drawbacks I can think of are: > > - others XML formats may require the same, but honnestly it's trivial > > - machine generated description (for example if the history log of > > a domain gets stored there) could grow a lot and I wonder if we > > have a hard limit on the size when transmitting xml descriptions > > Such a machine generated description would contradict the intention of > Rubin Simons for this description entry. IMHO this description entry yes but between a feature intent and how people (ab)use it, sometimes one need to be careful :-) > should be used for user-provided descriptions only. For any other > purpose (like a history log) another entry should be added. well no, a log should be maintained externally IMHO :-) > > Oh and I didn't found a good place to test the feature, i.e. no test > > seems to parse and reserialize XML it's always about conversions. > > > > Daniel > > > > ACK. > > This will be easy to support in the ESX driver, because a virtual > machine has an free-format annotation field where this description can > be stored. Okidoc, pushed, you can extend the ESX conversions then, maybe that will allow to test the round trip parse and restore too :-) thanks, Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ daniel@xxxxxxxxxxxx | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/ -- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list