Re: syntactic sugar vs. design

[Andrae Muys <amuys shortech com au>]

Havoc Pennington wrote:
[SNIP]
> ... you want scripts and command line tools to be able to transform
> and manipulate the config data easily. These are real design
> requirements for GConf.
> 
> Also, as I said in my original mail, we have the following key
> problems right now:
> 
>  - transaction support (make GConfChangeSet atomic)

AFAICT this is just a semantic change to the equivelent IDL functions? 
In which case becomes a matter of updating all current backends
(including those in devel) to correctly implement the new semantics. 
Granted the implementation of this is not trivial.

>  - the GUI admin tool
>  - working solution to per-session, per-display, etc. settings

I was thinking about this.  I really feel that we are making
insufficient use of GConf's schema support.  At the moment schema's do
little more then provide basic documentation.  I would suggest that we
could use schemas to provide such things as cache tuning, permissions,
ownership, and scope.

Note the issue of permissions/ownership.  This is critical, especially
once you start trying to deal with system defaults.  Remember one
critical design goal in this should be administrability, and you don't
get that without delegation of responsibility and that requires a
security model.

>  - a network backend such as LDAP
>  - improved test suite coverage
>  - finished documentation
>  - getting support for GConf in applications
>  - keeping things simple enough to use and implement
I would like to add to this list

 - develop a security model.
 - Migrate GConfClient to GObject [eliminate dependency on Gtk]

[SNIP]
> For structured data, I think being able to treat a GConf directory as
> an XML-tree-like-thing is a promising idea, because it smoothly
> evolves from the current model. That is, you could have a client-side
> subtree, and set that subtree as a value in GConf, or get a GConf
> subtree as a client-side data blob. So the API would be like:
> 
[SNIP API-example]

On this side of thing's how do people feel about using glib's N-ary tree
support?  (btw hp, I still feel that there should be convenience
functions to migrate between GMarkup and GNode :).  You could then
provide syntactic sugar similar to the example in my last email to
provide an easy mapping between struct, GNode*, GConf, (and maybe
GMarkup if hp is willing).

But we have to remember, the fundamental design concern is that any data
stored in GConf is stored as a directory tree of primitive types.

[more SNIPping]
> The primary penalty that persists is that you can't have lists of
> complex datatypes, other than giving them all a unique name
> (gconf_unique_key() kind of thing) and sticking them in a directory.
> The simplest solution to this is to allow GCONF_VALUE_LIST etc. to
> contain sub-lists. I rejected that for GConf 1.0 because it's a lot of
> implementation complexity. But it's an evolutionary extension of
> current GConf that's easy to do.

I'm not sure yet, but I suspect you can get away without the need to
provide lists of lists, provided you permit developers to declare them
in the schema.  Every directory stored in a list is going to have to
have a "primary key" anyway, so we can use that to provide a primary
key.  Yes you could have a list of directories, but then the list might
as well be a directory with a schema declared constraint on the
homogenity of its sub-directories.  I am not convinced by any stretch of
the imagination that there is any need to permit a list to contain
anything other then a primative type.  I would counsel a wait and see
approach, and only consider this complication if we see applications
forced to kludge around the limitation.

> So what would not be syntax? Changing GConf to basically be a
> simplification of LDAP and be tightly bound to LDAP; then you would
> allow queries and such. Or changing to a much more XML-centric model,
> with DTDs describing application preferences instead of GConfSchema,
> and maybe stylesheet transformations getting involved. 

mmmm I'm not entirely convinced that you aren't falling into the
"syntactic sugar trap" here :).  As it stands I think we could adopt a
very LDAPish query language for GConf, no redesign needed.  The
directory/key names would map to an LDAP dn's.  Of course the real power
of the LDAP query facility isn't it's query language (which is rather
clumbersome IMHO), but rather the standardised tree layout.  As far as
XML/DTD/XSLT is concerned, such things become natural extensions once
the GConfTree/GNode API is written.  However I think you are mistaken
when you talk about DTD's replacing GConfSchema's.  GConfSchema's are
already more powerful then DTD's when it comes to the subset of
XML-analogue GConf uses.  GConfSchema provides full type information and
documentation besides the structure definition.

Yes I would suggest that we look to evolving GConfSchema's ability to
define more flexible structures in the future.  But we couldn't maintain
the current functionality with DTD's without rather horrible hacks. 
OTOH, I have heard that XSchema does support type information, but I
don't know enough about XSchema yet to comment except to say that most
of the data-centric developers in the XML community appear to be heading
towards XSchema.

> Those would be
> fundamental redesigns. But so far no one is suggesting moving away
> from key-value pairs in what's essentially a giant hash table. So we
> are looking at pretty much the same GConf no matter how this is
> resolved.

I would like to see us evolve to a tree based API over a key/value
engine.  With convenience functions to move between Tree and C-struct;
Tree and GObject; and the ability to serialise the tree as XML/SML.

Andrae Muys