linux registry (no, not that again!)

[David Malcolm]

On Tue, 2004-08-03 at 11:48 -0400, Daniel Veillard wrote:
> On Mon, Aug 02, 2004 at 11:44:42AM -0400, David Malcolm wrote:
> > On Mon, 2004-08-02 at 14:11 +0200, Nicolas Mailhot wrote:
> > > On mer, 2004-07-28 at 10:18 -0500, W. Michael Petullo wrote:
> > > 
> > > > Also, as mentioned by someone else before, GConf has some interesting
> > > > capabilities.  As I understand, GConf also promised eventual multiple
> > > > backends. 
> > > 
> > > GConf promised to be a registry that avoided the maintenance problems of
> > > binary backends using XML. What the GConf people forgot is XML *can* be
> > > used to create human-readable and editable files (see fontconfig) but
> > > this requires some developer love to be true.
> > > 
> > > It's especially sad to see an app like evolution (which is supposed to
> > > be coded by elite Gnome people) abuse gconf files in so many ways
> > > they're almost as bad as a serialised binary blobs.
> > > 
> > > (take a look at .gconf/apps/evolution/mail/%gconf.xml if you don't know
> > > what I'm talking about).
> > 
> > It's XML stored as a string key inside the GConf backend, so you get XML
> > escaped inside XML.  Reminds me alarmingly of RSS :-(
> > 
> > Still, it's not quite as bad as a binary blob - at least you have a
> > snowball's chance in hell of figuring it out.
> > 
> > I hope I can get this fixed for Evolution 2.2
> 
>   I don't see the problem. If that piece of XML need to be stored in gconf
> it's just fine. The fact that the serialization looks taht way is not a
> problem in that case. Contrary to RSS, gconf is not about sharing structured
> content but about an API to a persistant storage, nothing need to be fixed
> there, it's like storing a template in a database, your database API
> is "load/store text" then on top of it you apply the specific semantic for
> the specific case where that text is XML.

Now, storing the various values in one big blob has the property that
changes and updates are atomic, and changing that could be a pain.

I think my main objection is that the UI for the gconf-editor is only
really set up for dealing with short strings.  Trying to locate a
particular XML-ified object in the list is really hard in the UI, since
there's no extraneous whitespace in the XML and the distinguishing
attributes are hidden in a region you have to use scrollbars to navigate
to (for each one in the list).  As an example, use the gconf-editor and
browse to /apps/evolution/calendar/sources, and, assuming you have a
large number of calendars set up, try to figure out which is which.

So if we accept that people are going to store XML-ified representations
of objects into GConf as strings - then the GConf tools need to provide
support for it.  For example, syntax-highlighting, maybe an option to
pretty-print a tree view of the XML (maybe even a mini XML-editor in
place).

Or maybe adding some judicious whitespace to the object serialisation
could help alleviate the readability/distinguishability.


> Daniel
> 
> -- 
> Daniel Veillard      | Red Hat Desktop team http://redhat.com/
> veillard at redhat.com  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
> http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
> 
>