linux registry (no, not that again!)

[David Malcolm]

On Wed, 2004-08-04 at 12:39 -0400, Daniel Veillard wrote:
> On Wed, Aug 04, 2004 at 11:28:35AM -0400, David Malcolm wrote:
> > 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).
> 
>   Well, it becomes a type system issue. Do you want to expand the 
> type system of gconf to understand XML instance or just keep as strings.
> That's an issue that came all the time as soon as people tried to store
> XML (or markup in general) within databases.
>   Do you really have a gconf limit on the length of strings stored ? 
No, the limit is on what I can use comfortably within the GUI; it's a
factor of this aging coder, rather than the architecture :-)

> Do you also have a limit on the character set (and encodings) allowed.
> I don't think adding an XML type will gain much in practice, and it will
> cost a lot. if the structure of the information isn't reflected in the 
> way it's stored, then that simply mean that it's not pertinent to check
> it at that level. For editing, as long as your cut and paste works correctly
> then any good XML editor will be better than what you can cook in
> the boundaries of the GConf tools, and using that should be way better.
> 
> > Or maybe adding some judicious whitespace to the object serialisation
> > could help alleviate the readability/distinguishability.
> 
>   please don't whitespaces are significant in XML, and would break any
> attemps at signing a key value.
What I meant was to add whitespace in the particular app that generates
the XML, in places where that app doesn't care about it when it later
reads the XML back in.  Although there's no actual DTD, the one implied
by the code has plenty of places where whitespace PCDATA in instance
documents is redundant.

The GConf side of things would faithfully preserve any whitespace; I
wasn't proposing to do any manipulation there; that would suck.


> 
> Daniel
>