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(a)redhat.com | libxml GNOME XML XSLT toolkit
http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine
http://rpmfind.net/