Re: GConf design goals.

[Dietmar Maurer <dietmar ximian com>]

Colm Smyth wrote:

> >>
> >> >> The problem is that applications are interested in accessing
> configuration
> >> >> information, but storing them in structures makes that information
> harder
> >> >> to access (except for the application that defines the structure
> that
> >> >> was stored) and more susceptible to breakage when the application
> evolves.
> >> >> For explanations and examples, see previous e-mails.
> >> >
> >> >We simply have a different view ;-)
> >>
> >> So *that* is the problem! ;)
> >>
> >> I've been specific about my concerns; could you try to explain why they
> are
> >> not an issue?
> >
> >Your answer to my mail today was:
> >
> >> >Hi Colm,
> >> >
> >> >that is not true. You can explore the contents of each CORBA_any with
> >> >the DynAny interface (see CORBA specs).
> >>
> >> No real application will do this; if they did, it would completely
> >> negate the convenience of storing a structure in the first place.
> >>
> >
> >I do not consider that very specific. What is "no real application"
>
> How many applications in GNOME use the dynany interface to store and
> retrieve data?

Not many, because most times you can use CORBA_any directly, since
you know the data types. An applications that have to use DynAny is
the generic configuration editor for example.

What other application needs to use DynAny? Please can you give more
examples where this is necessary.

> > and why
> >would it completely negate the convenience of storing structures?
>
> If I can write a structure using *one* call to the GConf API, but another
> application has to use the dynany interface or know the details of your
> structure to store configuration, I don't see that as a good solution.

I can't imagine that usage scenario. If I am interested in specific
configuration values I also know the types of these values. Maybe you can
give a "real world" example where this is a problem.

- Dietmar