Re: GConf and bonobo-conf

[Havoc Pennington <hp redhat com>]

Miguel de Icaza <miguel ximian com> writes: 
> Havoc, I do not understand how Bonobo-Conf is any different from a
> sysadmin perspective at all.  If you are going to say `command line
> tools' then a client bonobo-conf program can be written to do this.

No, not command line tools. (Though you are now talking about possibly
changing the bonobo-conf engine without changing the GConf engine,
which would make it quite different from the admin perspective.)

I don't know if bonobo-conf is different. But it should not be.
 
> Now, with the points I mentioned before, I want to point out that
> configuration data for per-session, per-display, system-wide can be
> very easily added to Bonobo-Conf without requiring API changes, for
> instance:
> 
> 	config:SYSTEM/DefaultPrinter
> 	config:DISPLAY/Desktop/Background/Image
> 	config:SESSION/Blah
>

That is not right, the application code should not be including this
information. Dig through the GConf archives. (But as long as you
aren't actually implementing it this way, I won't belabor the point -
just trust me, don't do it that way...)
 
> I do not understand how Bonobo-Conf `sacrifices system
> manageability'.

I didn't say it did - I said I have no problem with it as a GConf
wrapper as long as it doesn't.
 
> The proposal I suggested was to have GConf support the
> Bonobo:PropertyBag and Bonobo:Property interfaces as well as the
> current internal interface.  

Right, as I said, you didn't want to go through libgconf-client to
implement these in bonobo-conf.

> You forgot to mention in the `pros' section that using the Bonobo
> interfaces API would give us:

Because they also apply to implementing the thing as a wrapper, and
are therefore not pros of accepting this feature for gconfd itself. ;-)
My pros/cons list was for bonobo-conf as a wrapper, vs. bonobo-conf 
talking to gconfd itself.

> 	* Support for any language with CORBA support without the need
>           to wrap the GConf C API for that language.  

Works with bonobo-conf the wrapper.

> 	* GUI tools to edit PropertyBags is only going to get better
>           (we have an initial stab at this in bonobo-conf).  

Works with the wrapper.

> 	* The same API used to talk to controls and configure them
>           could be used to make system changes.

Works with the wrapper.

i.e. you still have not given a pro for talking to gconfd
itself. Which is all I had to say in my mail about bonobo-conf. I said
I have no problem with it as long as it works for sysadmins and users,
but I am not taking the patch in gconf itself, it has to be a wrapper,
and I gave a million reasons why. ;-) 

> 
> > There are reasonably good workarounds to the problem with GConf 1.0,
> > including:
> > 
> >  - store an XML document as a string at some key
> >  - store a serialized CORBA_any as a string; bonobo-conf
> >    could do this transparently
> 
> It does this ;-)

Yes, you are using a workaround, and it works, which is why I am
reluctant to put in extra hacks, see that is my point...
 
> The reason for using arbitrarly complex data structures is not done
> for "store everything in a single struct", but because nested data
> types are more powerful than regular key/value pairs of data.
> 
> In GNOME all over the place you can find file formats where a complex
> data structure has been "flattened" into the "address space" supported
> by gnome-config.  GConf suffers from these problems (For an example of
> such a file format, read the default.session file that ships with
> gnome-core). 
> 
> That is why it is nice to manually store configuration data in an XML
> tree, because you can describe data structures in their natural form,
> without having to flatten/unflatten them.

I don't disagree, as I said I'd like to have a way to do more
complex/structured data. In fact I gave a list of ways you can do this
for GConf now; picking the default.session file example, it's a lot
better with GConf because you can use directories, and in that
particular case I think GConf would work quite well. 

But in general you don't need to convince me of this, I think more
structured storage would be good.
 
> CORBA_any is just handy, because the API to manipulate it is already
> there.  I have no objections to an XML-based representation.
> 
> I would suggest to use the XML schema definition that is used by SOAP
> to encode arbitrarly complex data types (and we can also stream
> CORBA_any into those). 

Sounds like a potentially good idea.

> 
> >  - I'd like to keep implementation of apps and of the GConf
> >    admin/editor tool reasonably simple, so it gets done.
> 
> I am confused, can you give me an example?
> 
> If it is what I think it is, then you should not worry, because you
> can use monikers to get GUI elements to edit interactively data, or
> fetch programatically accessible properties. 
> 

Writing a GUI should not be super-painful, is all. I don't know if
CORBA_any would cause that, I'm just throwing out some design
criteria.

Havoc