syntactic sugar vs. design

[Havoc Pennington <hp redhat com>]

Hi,

A simple request; can we please separate the issue of syntactic sugar
from the issue of designing a configuration system.

Whether you use bonobo-conf or the GConf C API is a totally orthogonal
issue to the semantics and capabilities of the config system.

If we are just after "less typing" or "different naming scheme" or
"use as a CORBA object" then there are many ways to do that, from the
Nautilus wrappers to corba_any_to_gconf_value() convenience functions
to bonobo-conf. I can imagine a number of nice APIs here that would
allow easy interoperability with C structs. But that's really a tiny
issue of syntax.

We need to be clear on the desired semantics and capabilities, from
both an end-user and sysadmin perspective, and on what GConf will
support at the lowest level when you're using it in "fully powerful,
least convenient" mode. We can layer 1000 convenience APIs on top of
that, no problem.

But the architecture is what matters, and what should be getting
discussed. Once you are clear on the goals and design of the
architecture, you know how convenient the convenience wrappers can be
before apps become broken with respect to the design goals of the
system itself.

I've gotten private mail from a member of the bonobo-conf faction
saying "I think GConf needs a fundamental redesign and cleanup," but
at the same time bonobo-conf is almost _exactly_ the same design and
same data model as GConf. It is simply a trivial syntactic
remapping. Which leads me to believe that maybe people aren't
considering any of the design issues that actually matter.

Getting into specifics, I felt that Andrae Muys had an excellent point
about the general goals of GConf, and Colm makes an excellent point
that 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)
 - the GUI admin tool
 - working solution to per-session, per-display, etc. settings
 - 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.e. GConf needs to be fully productized/tested and some of the hard
enterprise-scaling problems need to be solved. Random API churn and
syntax rearrangement interferes with those goals in general. I think
we may want some nicer syntax in GConf eventually, but I'd kind of
like to see some broader testing in real apps to see what ad hoc
convenience stuff people come up with, and then use that as a starting
point.

The Nautilus wrappers do only two things really:

 a) automatically error check (I think they may have missed the point 
    that you can pass NULL for the error return and set a handler on
    the GConfClient, and GConf will automatically error check out of 
    the box, I did already think of this problem).

 b) avoid passing the GConfClient argument to the get/set calls.

Those can both be trivially added to GConf, we're not talking
rearchitecting anything, though as I said I'd sort of like more
testing before adding convenience API stuff.


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:

 tree = create_gconf_tree_thing ();

 set_value (tree, "foo", blah);
 set_value (tree, "bar", baz);
 set_value (tree, "baz/subtree", someothertree);

 gconf_set_value (gconf, "/foo/bar/baz", tree);

and when getting:

  tree = gconf_get_subbranch_as_tree (gconf, "/foo/bar/baz");

It's then trivial to write convenience functionality to go to/from
CORBA_any or to/from just regular C structs.

This preserves the simple directory hierarchy implementation of GConf
and the simple sysadmin/configtool view of things (a struct is just a
directory) but gives us a way to work with directories that isn't
painful, it's just get/set fields by name and then push the whole
struct into the database at once.

This also maps nicely to CORBA_any, you can replace the "tree"
variable above with a CORBA_any object, and have the same API. But
instead of storing a CORBA_any at a specific GConf value, we would
explode it into each field in the struct the CORBA_any represents. And
that way we still preserve primitive types on the GConf admin level,
and individual struct fields can be documented and edited without
having to use a GTK-based tool.

Which is to say, you can keep the simple directory-hierarchy design
and add syntax that is struct-looking or tree-looking, at least I
believe that's the case.

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.

In any case, CORBA_any is a variant data type. Variant data types are
a dime a dozen, there's also GValue even just within GNOME. I don't
see how it's anything more than a syntax issue. So the problems being
discussed are how the syntactic sugar of CORBA_any can lead
application programmers to mangle the GConf design goals
(upgradability, manageability, scripting). Valid concerns when picking
a syntactic sugar. But I still see no reason why CORBA_any has to be
in the GConf core, it remains syntax and syntax only.

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. 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.

My inclination as GConf maintainer is to prioritize the design issues
and productization, and let syntactic sugar evolve naturally based on
examples of actual application usage.

Havoc