Re: GConf and bonobo-conf

[Michael Meeks <michael ximian com>]

Hi Colm,

On Wed, 21 Feb 2001, Colm Smyth wrote:
> This is not purely a technology question, it's also a question of
> priorities.

	Fair enough.

> My perspective is that the main goals for a configuration
> system are that it is:
> 
> - a central interface (API and UI) for configuration access
> - a repository for stable long-lived configuration data
> - a way to share configuration with other applications

	This seems totaly reasonable.

> If GConf supported CORBA_Any at the interface level, it would be
> widely used because it would be simpler and easier than other
> solutions; absolutely no doubt there.

	Ok; so you might approve generaly of the CORBA_Any if it was
properly integrated into the GConf API and the evils of ConfigValue went
away ?

> The problem is that the GConf API was not designed to handle
> self-describing data; although you can use GConf to write a CORBA_Any
> (as XML, which is great), the interface is pretty crude since you
> write it as a string. This is basically turning GConf into a logically
> infinitely large indexed file and giving you an API consisting of
> read() and write().

	Yes, we logicaly turn gconf into a very strange ( string seeked
) read / write medium. It has some of the more useful advantages of gconf,
such as clever backends / mapping of the configuration space ( as far as I
understand ), but yes, 100% correct.

> For the application that creates the configuration data, this is
> heaven; you can write your data-structures and read them back easily.
> For any other application, or a different version of the same
> application that has a different version of the data-structure, this
> is bad news.

	Yes, again - this is true only if gconf refuses to do the sensible
thing and build the CORBA_any into the API, so there is no scope for other
applications to get confused. This is another reason why a single - bonobo
/ CORBA_Any based API makes so much sense - there is no half way house
for apps to poke around and get confused at.

> Some API's, such as DOM, are designed to handle self-describing
> data.

	I read a load of the stuff on the w3c site about the DOM, but I
didn't see specific mention of self-describing data - CORBA_Any's have
very explicit, well defined semantics for their introspection. This
coupled with eg. the standard DynamicAny interface gives any application
access to the arbitrarily complicated contained data via a standard API.

> This is fine, but it means that I can't use any of the power of SQL to
> query that data or perform fine-grained updates.

	I take the fine grained updates point, but then balance that
against the app developer having chosen this structure, and the huge
round-trip penalties we are talking about for repeated single key
fetching.

> Other applications can't easily view or update the elements of my rich
> data.

	This again is obviated by the pluggable, expandable bonobo-conf
TypeCode <-> Control editor mappings, allowing exotic types to be edited
in possibly 2 ways:

	* Plain old boring - simply show the structured data as it is
	using primitive type editing.

	* Pretty exotic - eg. a Bonobo/Color produces a color selector
	control.

> If you write a rich data-structure as a string to GConf, here are the
> disadvantages:
>
> - other apps have to "know" that this string is an XML document
>   corresponding to a specific data-structure and either manually
>   parse the DOM and perform an update (but how? attributes or
>   tags?) or know that this XML document represents a specific
>   data structure that could be converted back to a CORBA_Any

	Yes this sucks, however mandating the storage of richly typed
data, and removing the 'half way house' C API removes this issue.

> - if the data-structure evolves, then the ability to transform
>   the XML from a previous version of the data-structure is lost

	I do not believe this needs to be the case, any more than is so
than with gconf's structure currently. Conceptualy it is extremely obvious
to me that if we have a type description:

In the DB:
<types>
	<type name="a" value="long"/>
	<type name="b" value="string"/>
</types>

Requested Type:
<types>
	<type name="b" value="string"/>
	<type name="c" value="double"/>
</types>

	It is no trouble to discard a, keep b and return c as a default
value when fetching the config data.

> This seems to be saying "I'll gladly pay you Tuesday for a hamburger
> today" ;) or to put it another way, "I'll choose a quick solution
> today because I know that I can write a hard solution tomorrow".

	Not really, I was answering the objection that this is not
expandable / compatible in the same way across versions / structural
changes - and I believe I have demonstrated ( to my satisfaction ) that it
can be so. I can see two further possible objections -

	a) That you have to state the TypeCode you want
	b) That you get system defaults where fields are added, not the
	defaults you might want.

	a) is inevitable, and is hard-coded in source code for the current
	scheme ( in an upgrade )

	b) Can be obviated if this is a real problem by passing in a
	default CORBA_any, parts of which can be canibalized where
	neccessary, this is probably deeply useful anyway.

> I don't think that it's so easy to write code to parse the
> data-structure and migrate the data members to an updated
> data-structure, in fact I'm sure it's harder than writing the
> "serialization" (configuration-saving) code using GConf primitive data
> in the first place.

	Well, quite possibly. However, since we have all the neccessary
information we only have to write this code once for every user of the
system. Thereafter all users can transparently, trivialy and efficiently
map their structures beautifuly easily.

	This contrasts with a lot of replicated, slow, potentialy buggy
code to manualy map the values across. This seems feeble to me, if we have
the capability to represent the situation genericaly, why throw the
representation away as we compile hand written converters ? [ this is very
reminiscent of the ORBit IDL compiler's view of the world - broken 8].

> I am sure it's incredibly cool, but it's some cool technology on top
> of a system (GConf) that was designed with different goals in mind
> (easy to learn, easy to develop, easy to use); it was not designed to
> handle rich data.

	Fair enough, I take your point it is ugly having this
multi-layered API that allows apps to see rich data as strings - it
sucks. But I don't see that as a reason for not fixing GConf to store
rich structured data in future revisions.

> You didn't include the code that would be needed if you decided to add
> a new data-member to your structure; that is the part that's
> problematic when GConf can't interpret the opaque (but rich to the
> originating application) data that's being stored in it.

	This is shared code, written once in gconf / bonobo, yes it is
relatively non-trivial, but it is centraly maintained and can be made
bug-free.

> If GConf was *slightly* different, it would be easier; the problem is
> that GConfValue expects to own the actual data.

	A very similar problem to that already solved by CORBA_Any or
CORBA_sequence, that of the ->_release field.

> DOM is a very low-level API for XML documents, which you can find
> documented in many places but you could start with www.w3c.org. I
> expect that a web search-engine and the incantation "dom tutorial"
> would also be a good path to enlightenment!

	Thanks, I read some of this and it was most interesting although
rather disappointing.

	In conclusion, I'm confused as to what you are suggesting, whether
the rich data storage is not a priority for gconf, whether the current
setup (of being able to see rich data as strings) is broken (true), or
whether you are set against the whole idea of storing rich configuration
data (perhaps on the grounds of compatibility).

	Mail's rather long now, anyway, thanks for your comments, I await
your reply eagerly,

	Regards,

		Michael.

-- 
 mmeeks gnu org  <><, Pseudo Engineer, itinerant idiot