Re: GConf and bonobo-conf

[Havoc Pennington <hp redhat com>]

Dietmar Maurer <dietmar ximian com> writes: 
> I think the use of CORBA_any will simplify GConf a lot (you can still
> provide wrapper functions for simple types - even binary compatible
> ones). It will reduce the size of GConf.idl very much, since we don't
> need that strange union anymore ;-)

Assuming I could remove legacy support (which I can't), it would
reduce the number of lines of trivial code such as:

 switch (value->type) 
  {
    case GCONF_VALUE_INT:
     ....
  }

But it would replace those with something pretty equivalent. I don't
consider this important simplification; important simplification would
be to remove some of the "hard" code, this code is trivial either way.

But since GConfValue has to remain for compat reasons, CORBA_any would
just add another switch inside the above switch, and thus complicate
the code further. ;-) i.e. to get an int value, I have to check for
GCONF_VALUE_INT _or_ CORBA_any containing an int.

> 
> > 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
> 
> I already do this - but I can see no reason why this can't be done
> by GConf in the future.

The question is whether it should be done and why. That's the question
I'm not hearing a full discussion of.
 
> GConf depends on CORBA, so you always have to link against it. 

Only as an implementation detail. Putting it in the API is a much
larger step. Say GConf eventually is just an LDAP frontend; you have
to connect to the LDAP server over the network anyway; so CORBA won't
be doing anything.

The main alternatives to CORBA_any would be something more LDAP-like
or XML-like.

> And I don't see what's so bad with CORBA_any?

I didn't say it was necessarily so bad - I said there were a lot of
options, and they hadn't been discussed or explored, or I don't feel
like they have been. Since there are fine workarounds for now, I don't
see an urgent need to pick an option, I'd like to take the time to get
it right.

If no one has time to discuss the issue, e.g. a mail addressing the
various concerns I brought up in a serious way, addressing how things
would work for the sysadmin, how notification would work and be
efficient, how we'd document the struct fields, exactly what
end-user/sysadmin gains come from a CORBA_any in GConfValue rather
than serialized as a string, then no one has time to implement this
feature. Also, again as I said, I think it would be logical to give
GConf some time to be used in practice during the GNOME 2 cycle before
we make too many changes.

But again, I haven't made a yes/no decision here, I'm just saying that
I'm not taking the patch without due diligence.

Havoc

_______________________________________________
gnome-hackers mailing list
gnome-hackers gnome org
http://mail.gnome.org/mailman/listinfo/gnome-hackers