Re: GConf debate ... - the ironic hub.

[Havoc Pennington <hp redhat com>]

Michael Meeks <michael ximian com> writes: 
> 	I was misled into believeing it was public knowledge perhaps by:
> 
> 	http://www.europe.redhat.com/techworld/eventinfo_track1809.php3#03

Hmm, hadn't seen that. It is in fact totally bogus - we are not doing
any work to create the layer at this time and haven't done any
yet. So, apologies. Someone in marketing got the wrong info.

(Not that I think it would be wrong if we were doing work outside the
GNOME Project, as long as we didn't put it in GNOME without due review
by everyone involved, but just FYI we are not doing any at the
moment.)

> 	And I see that you could have got annoyed with me for going off at
> a tangent - but can you see how my suspicions are aroused that an
> anti-CORBA/Bonobo coup was going on:
> 
> 		* Which ORB should we use ?
> 		* Should we use Bonobo-config in Gnome ?
> 		* Why not just go for Gtk+2.0 and GL 1.4 ?

These concerns are all simply about the GNOME 2 release schedule and
what's feasible in that timeframe, rather than some hostility to
Bonobo, and were shared I believe by many people other than Owen and
I.
 
> 	As for GConf - I have no problem with using it as the single
> configuration backend, none at all, it seems to be more capable than
> bonobo-config in some ways - perhaps I should have mentioned this. I
> retain my objections to the GConf client API being part of the standard
> Gnome include headers - I would prefer the C client API to be deprecated
> and explicitely included if needed.

I agree it should not be in gnome.h, I don't like library
bundling. Apps should include and use the headers they need.

If the C API is deprecated that is purely with respect to the GNOME
Project, as a standalone project my current plans are to continue to
support the GConf API. wrt to the GNOME Project we don't have much way
to make a decision like this, of course. ;-)

I think we've agreed to use GConf as the backend. So there's no real
issue there.

Havoc