Re: Stage one finished

[Havoc Pennington <hp redhat com>]

On Mon, 2005-03-07 at 18:44 +0100, Philip Van Hoof wrote:
> 
> My (our) plans where to keep the current library as much as possible in
> tact in the hopes that we create something more or less backwards
> compatible.
> 

The most important back compat is with the user's data (file formats
etc.) rather than the programmer API. To move schemas to client side
(the valuable change) you have to break the programmer API.

>  2. Create a test-suite
> 
> Something for when we have something thats actually working.

I would write things in this order:
 - API and file format/layout specs
 - test suite using API
 - implementation of API

>  3. Create a new daemon or adapt the current to export DBUS
> 
> Since also the default xml-backend needs a rewrite (many people aren't
> satisfied with the XML-layout of the files, etc etc) this basically
> means rewriting most of not all of the daemon.

I would not rewrite the backend for now, I would save that for a
separate step. It's a lot of work and you have a hard user data
migration problem.

(The solution I would suggest is that you start writing out data in a
new format but remain able to read the old format, so you should be able
to get things started using only the old format)

> When I add 1 with 2 and 3 .. it basically means rewriting GConf from
> scratch. :-)

No, if you rewrite from scratch you will get it wrong. The new codebase
may have very little of the original gconf code left unchanged, yes; but
there's a difference between that and from scratch.

That's why http://www.gnome.org/projects/gconf/plans.html is phrased as
a delta vs. current gconf, rather than a standalone requirements list.

> I came under the impression that GConf has all required features and
> that rewriting it would be foolish. But now the original author of GConf
> (afaik thats you, Havoc) is basically saying that perhaps it does need
> an (almost) complete rewrite. So I'm a bit confused. Haha ;)

It does not need a rewrite, but it would benefit from a careful addition
of the fixes mentioned at http://www.gnome.org/projects/gconf/plans.html

Where you are today is that you don't understand why gconf is the way it
is, and which things are features and which things are bugs/accidents.
So designing from scratch is going to be a major mistake.

Havoc