[linux-elitists] Re: Yet another mozilla atrocity
Tue Oct 7 22:55:21 PDT 2003
On Wed, Oct 08, 2003 at 12:11:50AM +0100, Karsten M. Self wrote:
> - Data storage formats can be opaque: previously cited Evolution
> instances for "My Weather" and "My Headlines". Which I'll note the
> GNOME crowd here have punted on identifying or decoding.
I'm willing to bet this is a "arbitrary data typing is hard!" problem.
When you create a storage system like gconf (or similar; X resources
are also like this, for instance), one advantage is that you get to
type your configuration keys -- this is a string, this a boolean, etc.
Which is great, except then someone wants to store a dictionary
mapping strings to lists of booleans, and your choices are basically
either 1) build a complete type system into your database (maybe using
XMLRPC's marshalling format or similar, I guess), or 2) shoehorn stuff
into the string type in some ad-hoc coding. (For an example of (2),
think of the quirky little mini-grammar that Motif apps store in X
resources for keybinding overrides.)
Neither of these choices is nice at all. There are significant
engineering benefits to working with a typed storage backend rather
than writing Yet Another Ad-hoc Configuration Language. But with (1)
you get lots of complexity and probably still end up with impedence
mismatch between database types and code types, and with (2) you're
back in the world of unchecked mini-grammars that are resistant to
automatic modification. I don't know what the right answer to this
is, but it's a nasty little problem.
> - Data storage structure doesn't allow comments or commenting out
> settings on a temporary basis.
Similar sort of problem; one of the big issues with traditional
configuration files is that they're not at all machine-editable.
The typical solutions is to have two sets of configuration, one
written by the program and one written by the user; precedence is
unclear, and you end up with files that look like the user
configuration file except they say "DO NOT EDIT!!!" at the top and
indeed, trying to change options set inside those files tends to have
hard to predict results. (In the worst case, you may be stuck with
two disjoint sets of options -- ones modifiable from the UI, and ones
modifiable by editing your user configuration...)
An interesting endeavour would be to design a generic configuration
file format that is sufficiently free form to be comfortable to edit
by hand, include comments, etc., but sufficiently strict to make
programmatic viewing and modification of arbitrary settings possible
(while preserving comments etc.!). I guess XML could work for this,
but I don't think people use XML like this right now, and it's hardly
as comfortable as a .muttrc or the like...
"The problem...is that sets have a very limited range of
activities -- they can't carry pianos, for example, nor drink
More information about the linux-elitists