GConf design goals: a summary?

[Byron Ellacott <bje apnic net>]

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.
2) A structure makes generic editing, ie by a script, or a tool for some
   sort of user interface, more complex.
   - 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.
   - These same nice Bonobo components can use the convenience API and not
     even be aware of the data mapping being done.
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?
   - 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.

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.
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.
   - Using a GConfSchema, or a future evolution of that, you can provide a
     plaintext description giving more detail than the above.
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].
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?

> 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.

[0] I call CORBA_Any a heavily complex type because, to avoid brittleness
and type unsafety, you need to fully utilize the self describing features
of it, and that's work the application needs to do.

-- 
bje