GConf and bonobo-config - some ideas

[Elliot Lee <sopwith redhat com>]

So here's what I understand so far:

As far as I can tell, it is not really "GConf vs bonobo-config" any more -
it is more an issue of how to merge the features of both into the final
solution. I have not seen any huge reasons that would warrant dropping one
and using the other exclusively...

The benefits of bonobo-config:
1. Using CORBA_any, because it allows config values to be complex data.
(See 'Things to do', however.)
2. Using bonobo interfaces (I haven't yet understood why this is good, but
everyone else likes the consistency :-)
	(a) App-level CORBA API that doesn't require wrapping for
	other languages [*]

Agreements so far:
. Use bonobo-config as the main API presented to GNOME application
developers, with the GConf C API used to implement the gconf/config
moniker.

Things to do:
. Everyone needs to to reaffirm their committment to Bonobo as the
component/document model for GNOME 2, because the feeling by the Bonobo
hackers is that many people are not on board with their efforts.

. Because there is an option for people to use other config 'monikers',
explicitly choose GConf as the config data system of choice, and address
any issues that prevent GConf from being used for everything
config-related.

. Concerns that bonobo-config lacks testing need to be addressed by
porting the gconf test suite to bonobo-config. This is an independant task
that could possibly go on the TODO list (whee!).

. Address concerns that the GConf schema and other GConf features are not
being exposed properly by the bonobo-config API.

. Address concerns about XML backups (?)...

. Solve CORBA_any problems (property editors, no of upgrade path), and
deprecate use of complex types until solutions to these problems are
found. Since we managed to do fine with gnome_config, we can probably do
swimmingly with the complex types that GConf provides, in the meantime...

. (Longer-term) The process of "figuring out things" needs to be improved.

	(a) One thing that can be done without much additional effort
	or complexity is having people produce formal, more detailed
	statements of agreement "signed" by all parties involved.
	I recall too many instances of people "agreeing"
	on an issue months ago, and subsequently seeing one of those
	people denying an agreement, or disputing one of the supposed
	details of that agreement. I have attached a stupid form
	that might help to this end, but should this fail to
	be used I'm sure 10-page contracts can be arranged instead :)

This is not complete. I suspect Havoc & Dietmar will be able to fix up and
clarify this list, I just wanted to spew what I knew to help make sure
people are really truly agreeing this time. :)

Hope this helps,
-- Elliot

* Using Bonobo directly via CORBA is painful, and no current examples of
this exist, so the benefits of this are hypothetical at best.

	Hacker's contract

Summary:

Details:
1.
2.
3.

Agreed, YYYY-MM-DD by: