Re: GConf design goals: a summary?

[Dietmar Maurer <dietmar ximian com>]

Byron Ellacott wrote:

> On Mon, 5 Mar 2001, Dietmar Maurer wrote:
>
> > We have talked about type aliases, and I have pointed out how we can
> > use special editors to provide a nice UI.
> > I think this will never get a useful discussion if we arbitrarily
> > merge problems/solutions.
>
> Let me try and get clear what we are discussing:
>
> I am arguing against including complex data types in the GConf data
> scheme, yet not arguing against providing a GConf level API for complex
> data type mapping to the simpler data types.

>
> My reasons for this argument are:
> 1) The more complex the data type, the more brittle it is
>    - The counter argument is that a CORBA_Any type is self described, yet
>      the mapping from a self described type to the data actually present
>      in the backend can be done by a convenience API.

"brittle"? My dictionary says "brüchig, spröde" - maybe you can
be more specific.

> 2) A structure makes generic editing, ie by a script, or a tool for some
>    sort of user interface, more complex.

If someone stores a value as structure he decides that you should treat it as

atomic value. It makes no sense to modify only parts of the structure. So if
you
do not store complex types you have to provide some sort of transactions,
which
is as complex as handling DynAny.

>    - The counter argument appears to be that components can be provided.
>      This provides a solution to *one* part of the problem, namely, GNOME
>      user interfaces.

You can also provide a nice command line editor -why not - what is the
problem?

>    - These same nice Bonobo components can use the convenience API and not
>      even be aware of the data mapping being done.

Sure.

> 3) Presenting a CORBA_Any data type in the basic API creates a dependency
>    on CORBA types at the API level for apps that otherwise wouldn't care
>    what transport mechanism GConf uses.
>    - I can't see a clear counterargument for this?

One have to define a API to use the extended functionality. The use of
CORBA_any
is IMO a convenient solution, since GConf already depends on CORBA.

>    - If the data model isn't based on a CORBA_Any, the more complex API
>      can simply be in a separate header file, to reduce namespace clutter
>      where it's not needed, but to be part of GConf.

You can always define some wrapper functions.

> So, from your perspective, recent arguments I've seen include:
>
> 1) CORBA_Any is more than just structs, for example enumerations
>    - Colm provided the counterargument that GConf already provides a
>      mapping from a string value to an enum, which gives the same degree
>      of type safety and upgradability as the CORBA_Any enumeration.

The point is that I can also do it with CORBA_any - the whole code already
exists in the DynAny interface.

> 2) CORBA_Any allows type aliases, thus giving more information to tools
>    - Unfortunately, I cannot see how a new name for a type gives any more
>      information to any tool except one that knows how to deal with it,
>      either by hardcoded logic or interface specific plugins.

I can see many advantages. Simply take the ContentType alias. With GConf
you have to edit a string to set the mime-type. Bonobo-conf can provide you
with a highly specialized editor presenting you a list of possibilities.
Isn't that
an advantage. What is the disadvantage of plugins?

And CORBA_any also have list/arrays.

>    - Using a GConfSchema, or a future evolution of that, you can provide a
>      plaintext description giving more detail than the above.

Nothing prevents you from giving plaintext descriptions, but you also need to
store the enumeration names and there order if you want to check if the two
types are compatible.

> 3) CORBA_Any is very convenient for an application
>    - Yes, it is.  This isn't an argument for putting it in the data model.
>    - It's also only convenient for a subset of applications, and that is
>      those that are prepared to use a very heavily complex type for their
>      config data [0].

I would use CORBA_any even instead of that GConf value union, simply because
it makes the GConf code simpler. As Havoc already pointed out this is a
GConf internal implementation detail. I think using CORBA_any makes sense
even if you only store basic types. So it seems obvious to me to use
CORBA_any
also in the data model. Why should we do conversions between several data
models?

> 4) corba_any_to_string() limits access to this structure to those apps
>    that can deal with that encoding.
>    - An API to map a CORBA_Any to the simpler GConf types gives access to
>      any tool that can handle the simple GConf types.
>    - A directly stored CORBA_Any limits access to the structure to those
>      apps that can deal with a CORBA_Any encoding.
>
> I'm sure you have more points, but I want to be clear that this is what
> we're arguing: that CORBA_Any belongs or does not belong in the GConf data
> model.
>
> I am not at this stage arguing whether it belongs directly in or very near
> to the GConf API, and I believe Colm is debating on the data model level
> also... are you?  And if so, what are your reasons for believing GConf
> should be based around the CORBA_Any behind the scenes?

I think I have already pointed out what can be done by using CORBA_any. The
CORBA_any/DynAny specs are also available to everyone. Every time I point out
a nice feature someone else say "sure, but I can also do this by implementing
...".
Sure, we can implement an DOM like interface, or somebody even suggested to
implement transactions. I can live with any GConf implementation that
supports all features of CORBA_any, but does not use CORBA_any directly.

The whole discussion always gets to the same point: If you use structure you
have an upgrade problem. People tends to neglect the fact that the upgrade
problem always exists. If I use CORBA_any I have strong type checking, so I
can detect that I have an upgrade problem.

Another point is that it is simply not possible to restrict programmers from
doing certain things. The best example is bonobo-conf itself. Although GConf
does not support to store complex types I have found a workaround. So you
will never reach you goal that everybody stores basic types. Instead we will
have multiple workarounds, which is certainly the worst situation I can
imagine. Complex types exists and we have to provide a solution to store
them.

> > The generic editing problem is totally unrelated an was already
> > discussed.
>
> I don't recall us reaching an agreement to this.  Quite the contrary,
> developing a console based administration tool, I think this point is
> *highly* important.

It is absolutely no problem to write a console based administration tool that

can handle CORBA_any.

- Dietmar