Re: Panel's GConf usage

[Michael Meeks <michael ximian com>]

Hi Havoc,

On Fri, 2003-02-21 at 17:21, Havoc Pennington wrote:
> > 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.

	Well - AFAICS the panel has the same type of problem; so it seems on
the face of it that it's unlikely to be that uncommon. A hypothetical
example:

	* XChat
		+ server list
			+ auto-connect
			+ nick strings
			+ port server

	In fact any app that deals with 'multiple things' is going to suffer
from this. Of course - in many circumstances, there are existing
namespaces which can be used to construct key names, and make it seem
less artificial - where essentially you still have a small un-ordered
list of structured data. Whether that namespacing decision may enforce
unwanted constraints on the design later is an interesting question.

	The mess in apps/panel/profiles/default/applets looks pretty horrifying
- but in fact is a feature (?) and simply the only way to do un-ordered,
non-namespaced lists.

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

	That's true enough - certainly when there is some namespace you can
leverage to try and get over this problem. However - in many non-trivial
situations, all you want is a simple non-ordered list of some type - and
you don't want to have to go creating manipulating random directories
yourself, and/or dealing with collisions, culling stale ones, etc. [ I
guess ].

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

	It's interesting that you see bonobo-conf may have a role for storing
data (locally), rather than gconf for preferences. My feeling is that
bonobo-conf is dead, we're stuck with gconf - and we need to be pushing
the envelope on it's API to make it more powerful.

> 	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

	It's sensible enough, because both suck - however the constant creation
of new type systems is an efficiency and learn-ability tragedy. 
> because I think Linux (and UNIX) need a standard desktop configuration
> system.

	And you seriously think that GConf can be it ? I'm amazed. I would
imagine that sharing code across desktop projects will never work,
although - some innovations might assist that; such as shared
maintainership / re-locating.

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

	Almost certainly not, but that's a protocol issue more than an end-user
API issue surely.

> The current design simply has not *considered* the issue of storing
> data.

	There is the critical issue of disconnected operation, which it seems
every design so-far has not addressed.

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

	OTOH - if we stuff all the data in there that needs to be configured,
we'll have an idea of the API we need to do that, and the true scope of
the problem we're trying to tackle.

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

	That's most encouraging and helpful; thanks. I was worrying that your
next 6 months might look like:

	* D/BUS:
		+ re-write chunks of glib,
		+ re-write chunks of linc
		+ re-write chunks of ORBit2
		+ re-write chunks of bonobo-activation
		+ re-write chunks of libbonobo
	etc.

	I'm encouraged to see, that that's not the case yet.

	Regards,

		Michael.

-- 
 mmeeks gnu org  <><, Pseudo Engineer, itinerant idiot