Re: Panel's GConf usage

[Havoc Pennington <hp redhat com>]

On Fri, Feb 21, 2003 at 11:42:31AM -0500, Ettore Perazzoli wrote:
> On Fri, 2003-02-21 at 09:08, Havoc Pennington wrote:
> > On Fri, Feb 21, 2003 at 10:17:43AM +0000, Michael Meeks wrote: 
> > > 	So - say I want to store an array of structured data; eg. containing a
> > > couple of strings, a few doubles, a long or two - what do I have to do ?
> > > is it a matter of making up a random sequence of sub-directories
> > > etc. ?
> > 
> > You can do that, or you can encode it somehow. There are various
> > approaches. I don't know of any apps that actually do this though.
> 
> I believe it's a rather common situation to have this kind of setup.  We
> had a fair amount of trouble migrating Evolution from bonobo-conf to
> GConf precisely because GConf has no notion of structured data.

I can believe something like Evolution has this situation (and would
be interested in the specific use cases just to help me think about
future work, plus how you solved it - serialize to string?), but I
can't think of many examples in smaller apps. And it *is* easier if
you plan for gconf in advance, instead of porting from bonobo-conf
where you'd already structured the code the other way. I would not
even ask you to port from bonobo-conf if bonobo-conf works fine for
you.

Remember that I've often warned/documented that gconf as it currently
stands is not good for storing *data*, vs. *preferences* - by data I
mean things like address books. I do think we should unify the data
and preferences systems, but gconf needs work to be that unified
solution and the reason I've always said it's preferences only is that
the work hasn't been done. I would also agree that the line between
data and preferences is a bit fuzzy.

There's a simple short-term approach to storing "structs," which is
the same one we are considering for "color" and other such types; to
have a hint marking that the string (or array, or whatever) is to be
interpreted in a particular way by gconf-editor, then encode the
complex type as some primitive type (string or array).

If we had a decent standard type system I'd be willing to use it on a
more fundamental level, but I don't want to be bound to either GType
or CORBA for the long term, because I think Linux (and UNIX) need a
standard desktop configuration system. This is why keeping the type
info relatively peripheral is the way I'd like to go for now.  If
someone wants to write CORBA_any_to_string or
CORBA_any_to_binary_array and use that I have no problem with it other
than "it sucks a bit in gconf-editor and automated scripts", which
could be addressed using the "hints" feature.

The main issues in my mind regarding storing data in gconf are the
interactions of that with plans to make gconf more "enterprise
friendly" as in my OLS talk (see OLS 2002 proceedings for the paper).

If your gconf database is suddenly out on the network somewhere, is it
going to be a bad idea for example to have tons of data in it?  If we
have large data in there, will the current protocol which always sends
new values out with the notification scale? Does it make sense to
store data before we have atomic transactions/changesets?  Are there
privacy/security issues with sending someone's address book over the
network? These kind of questions need answering. The current design
simply has not *considered* the issue of storing data.

So this needs to be addressed, if we just start stuffing all kinds of
data in there users are going to lose data, or things are going to be
slow/buggy, or we're going to limit future enterprise/standardization
enhancements.

My hopes for what I will work on over the next 6 months are:

 - implement the new proposed menu vfolder specification (yes, yet
   another vfolder backend, and yes I *hate* the idea of having to
   spend a month on this but it is a major problem for Red Hat Linux)

 - spend substantial time clearing out
   gnome-terminal/metacity/pkg-config/gconf patch/bug backlog

 - work on a "lock down mode"

 - work on gconf enhancements, mostly in the area of 
   resolving "enterprise" issues and general cleanups; 
   also probably moving to GCONF_LOCAL_LOCKS by default. 
   Read the OLS paper for a starting point on the kind of
   work that I'm thinking of.

Havoc