Re: GConf design goals.

[Andrae Muys <amuys shortech com au>]

Colm Smyth wrote:
> 
> Hi Andrae,
> 
> Thanks for your support, the bonobo-conf thread has become a little
> weary but it's nice to know that other developers see some of the issues
> with this proposed feature.
> 


Actually I can't think of anything more important to talk about on the
list than the design and architecture of GConf.  Ultimately one person
has to say "This is what we are going to do", but within that discussion
of the final design is important.

OTOH, I agree this specific thread will only start looping if we don't
start discussing concrete examples, suggestions.  This is why I made my
(rather poor) beginning yesterday.  Specifically, the bonobo-conf
developers are wanting solutions to specific developer focused API
concerns to be included in GConf.  From what I understand (I am sure I
will be corrected if I misunderstood), it isn't a matter so much of
wanting a variant-data-type in GConf, as wanting strong API support for
GConf based serialisation of structs.  The concerns to be balanced with
this desire are administrability, and flexibility as applications
evolve.  Of which I can't think of any way to achive the former without
achiving the latter, so we can focus on the trade-offs between developer
comfort and administrability.

Some of the GConf features that support administrators include :

 - Independent of backend.
      Permits the integration of GConf with existing enterprise systems.
      Eliminates the scalability limits implicit in a hardwired backend.
 - Independent of GUI.
      Permits development of console utilities that permit efficient
remote
        administration.
      Permits development of scripting utilities that permit automation
of
        GConf data migration, administration.
 - Independent of domain.
      Permits the development of generic tools capable of manipulating
the
        GConf datastore without requiring any application domain
knowledge
        beyond that stored in the GConfSchema within the datastore.

An additional benifit in the current design mentioned by Colm unrelated
to administration, but worth mentioning...

 - Independent of transport layer.
      Permits the deployment of GConf to applicances where an ORB would
be 
        an unacceptable.

Now as far as I know, no-one has suggested a means by which we could
provide native Variant support within GConf and retain the top three
features.  Also, no-one has suggested a reason why the various
syntactic-sugar API suggestions are inadequate to provide the requested
developer convienences.

Miguel suggests that vi(and therefore presumably sed/awk/perl/etc) can
be used to provide GUI Independence.

1/ (re. hp) As this bypasses gconfd, vi can only be used when the daemon
is disabled or we break the gconf notification/caching/synchronisation
model.  Then bad things happen.

2/ We loose backend independence.  We would then be left to
learn/develop a different administration tool for each backend.

3/ We loose the ability to leverage GConfSchema annotations to provide
help/tooltips/type information (although bonobo-conf seems to use it's
own type annotations?)

4/ We loose the ability to provide implicit locking/transaction support.

I would suggest these costs are too high when alternatives exist that
have not been demonstrated inadequate.

(feh, if I had the time, I'd just write the blasted synsugar API and be
done with it)

Andrae Muys

P.S. As far as vector/pairs are concerned they are technically different
from Variants as they only ever contain homogenous types.  They are
semantically different as they are conceptually a single value, rather
than an aggragation of multiple values.  Granted it took an 1.5 hour irc
"discussion" with Byron to explain both the difference and why it is
important.  It's mainly a matter of transactional control and locking. 
The only thing we agreed on entering the discussion was the
undesirability of user-managed explicit distributed transactions in
GConf :).