Re: Duality (was Re: gnome-config problems)

[Jim Pick <jim jimpick com>]

Jason Gilbert <jason@scott.net> writes:

> Jim Pick wrote:
> > 
> > 
> >             SGML approach                S-Expression approach
> > 
> >    +-----------------------------+  +-----------------------------+
> >    |          Core App           |  |          Core App           |
> >    +-----------------------------+  |   (includes simple parser)  |
> >    |      SGML Parser & DTD      |  +-----------------------------+
> >    +-----------------------------+  |          Raw Data           |
> >    |           Raw Data          |  | (s-expressions, must match  |
> >    |    (SGML, must match DTD)   |  |       code in core app)     |
> >    +-----------------------------+  +-----------------------------+
> 
> Of course, as far as gnome is concerned the Core App would only be
> accessing the config stuff through the gnome_config API.  So, the parser
> in the schemem case would be below that.  Right?  the configuration
> storage method is supposed to be abstracted from the access API.  Or, is
> the Core App the API is these pictures?

The diagram is intended to be for a generic application, with no
reference to Gnome.  How the Gnome libraries would want to do it is
anybody's guess.

I'm of the opinion that how an application stores it's data is the
domain of each individual application.  They may choose to use a set
of services provided by the Gnome libraries if those services fit the
bill.

At this point, I think the config file interface is just dealing with
a way of providing a service for making certain bits of data
"persistent".  Sort of like the Window profile_string (ini file) or
registry functions.  Nothin' fancy.  It doesn't really matter how it's
implemented - that's for the Gnome libraries to figure out.

A generalized configuration interface that also incorporates UI and/or
client/server interaction is a whole other ball of wax.  I proposed
using a special-purpose configuration language a few weeks ago, which
I'll have to follow up on with some code sometime.

Be very careful about confusing how config data might be stored vs.
thinking about other file formats.  We'll support zillions of
different document types and languages, each of which will have a
different syntax or file structure.  When you're talking about
modifying gtk-xmhtml to understand special tags to render a menu,
you're really talking about using a document or language input file -
not using a config file interface.  So modifying that HTML-like input
file isn't really a case of twiddling config settings - you are really
editing a document.

Perhaps we could do without config files at all, and consider
everything to be just documents that could be edited.  That's where my
proposed configuration language might come in handy.  But that's a bit
radical and not practical at this point of the game.

Cheers,

 - Jim

PGP signature