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 ? 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. Daniel -- Daniel Veillard | Red Hat Desktop team http://redhat.com/ veillard@xxxxxxxxxx | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
