Re: GConf debate ... the hermenutical key.



[cc: list cut down]

On Mon, 18 Jun 2001, Dietmar Maurer wrote:

> Sander Vesik wrote:
> 
> > On 17 Jun 2001, Havoc Pennington wrote:
> >
> > >
> > > Miguel de Icaza <miguel ximian com> writes:
> > > > We are talking GNOME 2.0 here.  And we have broken more APIs for this
> > > > release that I can list in the next couple of hours (speaking of Gtk+
> > > > only here).
> > >
> > > My point is that if bonobo-config is a wrapper, there's simply no
> > > reason to break the API. Or the implementation.
> > >
> > > > Few applications use GConf and it would take little effort to migrate
> > > > them to a better system.  The only limitation to do such migration
> > > > would be pride.
> > >
> > > First we have to establish that we have a better system. ;-)
> > >
> >
> > Another thing - people still working on getting their application ready
> > and doing so on gnome-1.4 can very esily make use of gconf and then when
> > moving to gnome-2.0 just not touch that part of the code - essentially
> > foregoing the need to retest a non-trivial part of their programs
> > (preferences).
> >
> > I would really hestitate putting the requirement 'must use bonobo-config
> > for configuration' as a requirement for application in gnome-2.0
> > especially as gconf is (and to the best of my knowledge, has been there
> > for a while) - whatever the ultimate direction in configuration management
> > for GNOME is.
> 
> They current approach does not force someone to anything. Instead it is a
> step to be independent of the configuration system, since we only defined a
> client side CORBA API to access configuration data. This is the main point
> you do not understand.
> 

Dietmar, please read what I wrote. Where do you see me claiming that the
'approach' forced people to change? 

> > It is in my opinion very unlikely that gnome-2.0 will not be a mix (at
> > best) of gconf and bonobo-config and I'm not sure even suggesting
> > application developers/maintainsers that adding port to bonobo-config is a
> > prudent advice.
> 
> What you suggest is to keep the gconf API. I would agree if you say we need
> that for compatibility reason. But instead you want application developers to
> continue using that interface, instead of using a clean client side CORBA API
> to access configuration.
> 
> But I am really getting tired to explain why it is better to use a CORBA
> interface. Feel free to use whatever you want.
> 

I can see why a GNOME and only-GNOME application might be better off using
*A* CORBA based API for configuration access. For others, gconf sounds a
lot better solution ('cause you just need to pull in less non-native
code).

You have basicly offered no proofs for almost any of your claims, among
other things that it completely wraps the gconf api on the functionality
side, that it provides similar or superior error reporting and recovery.
It does not appear to have any test code (or for that matter, a place to
report bugs). 

Whetever I agree or not is largely immaterial - convince the app
developers - hells, for that matter, take the damn trivial time and post
an overview of where what and why (preferably taking the time to prove any
claims) to gnome-hackers and gnome-devel-list!!! For all anybody cares,
discussing configuration systems in gnome-components is the same as doing
so in giant-space-hamsters. 

>
> - Dietmar
> 

	Sander

One day a tortoise will learn to fly
	-- Terry Pratchett, 'Small Gods'






[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]