Re: GConf and bonobo-conf

[Byron Ellacott <bje apnic net>]

Woah.

That'll teach me to not check this folder for a few days.

I have an interesting perspective on this problem, since I am using gconf
in two ways: in an application I am developing, and in a tool for gconf I
am writing.

Now, from the application's point of view, a CORBA_Any type doesn't give
me any benefit.  My application doesn't use CORBA directly as things
stand, and I'd rather not clutter its namespace further to add a type I
wouldn't want to use, especially given that type can be easily synthesised
already.

Other applications may get a benefit.  The benefits I think I've seen so
far are:
  * No need to flatten types
  * One call to read/write these types, instead of many
  * Bonobo-conf uses CORBA_Any already (?)

Now, if I can address each point individually:

As I believe has been mentioned, you can use a GConf subdirectory to avoid
flattening your structure quite easily.  There are other benefits to this
approach I will cover later.  From my point of view, I see no difference
in complexity between requesting "/apps/my/app/struct/field1" and
requesting "/apps/my/app/struct"->field1, save you don't need to manually
reconstruct your data in the second case.

This relates to the one call issue.  Two routines to read/write CORBA_Any
as subdir/field subdir/field will completely eliminate this issue.  It
will make the above also irrelevant.  It also has the other benefits I'll
discuss below.  The other side to this is while my code only makes one
call, I am doing more traffic across the network connection.  I don't
have a direct answer for this, rather that the CORBA_Any doesn't seem to
offer enough of a benefit to justify the small cost saving.  Perhaps a
write cache would be workable, so a number of temporally close writes can
be sent as a single network call.

Bonobo-conf, with its GUI property sheets, may be quite a logical place to
use CORBA_Any types, but as Havoc I think said, this is no reason to add
it to GConf as a supported data type.  It may be a very good reason to
have Bonobo-conf calls to save/load CORBA_Any types, though.

My application, for instance, will store geometry information for its
major windows.  I'm currently stumped because the GtkPaned won't let me
get the last set position value, but that's tangential.  I *could* create
a structured type for x,y,w,h, but that has downsides: it's harder to add
the GtkPaned's position for the main window, yet leave it out for the
subwindows, unless I have unused fields.  I intend to do it in the method
I outlined above, with mainwin/x, mainwin/y and so on.

The benefit of this approach is upgradability.  If I remove a field, I can
simply ignore the extra key in the config space.  Perhaps my upgrade
Makefile target can use gconftool to drop that key, even.  If I add a
field, I simply specify a sane default value.  I can write an upgrade
script using gconftool to convert values, in the case of (r,g,b) ->
(c,m,y,k), or my app can check for (c,m,y,k) and then for (r,g,b), if I
want to be transparently backwards compatible.  If I get tempted to use
CORBA_Any types for this, there's no way to keep this level of
flexibility.

And now we get to the tool's point of view.  I am writing a console based
tool to maintain GConf repositories.  It currently will browse the
repository, and when time permits, it will allow you to edit the basic
types.  Adding complex types to GConf makes tools such as this one much
more complicated.  For a start, screen estate will need to be managed
carefully - if you define 26 fields, and I'm on an 80x24 column, I could
be in trouble.  As a user, I also have to deal with this entire set of
information at once, rather than one piece at a time.

I also once again have to be able to deal with the CORBA_Any data type,
when my application has no direct use for CORBA.  If a good case for
complex data types being directly supported by GConf was presented, I
would accept it, but I wouldn't agree that CORBA_Any was the right, or
even a good, type to use.

One final argument against CORBA_Any:

If at some time in the future, things shift to use SOAP[0], and Bonobo v3
uses SOAP objects instead of CORBA_Any, you'd be stuck doing a conversion,
or you'd be requiring another addition to the GConf API.  A major argument
for CORBA_Any (that specific type, not necessarily structured types in
general, though I've made a case against those, too) is apparently that
Bonobo-conf uses that type, and it'd be nice and easy to have it supported
directly.  I say it causes far more trouble than avoiding a wrapper
function in the Bonobo-conf API deserves.

For those interested:

http://users.bigpond.net.au/mlm/planner/
http://users.bigpond.net.au/mlm/gconfsole/

for the application and tool, respectively.  Andrae Muys has added
gconfsole to the gnome-console project, the version above is the proof of
concept I released.

The application has only recently converted to GConf, so it's a little
rough, but the default values code is there and working.  Also note that
the application is a GTK+ application, not a Gnome app.

-- 
bje