Re: GConf design goals.



Dietmar,

>Delivered-To: gconf-list gnome org
>From: Dietmar Maurer <dietmar ximian com>
>X-Accept-Language: en
>MIME-Version: 1.0
>To: Colm Smyth <Colm Smyth Sun COM>
>Cc: gconf-list gnome org
>Subject: Re: GConf design goals.
>X-BeenThere: gconf-list gnome org
>X-Loop: gconf-list gnome org
>X-Mailman-Version: 2.0beta5
>List-Id: Discussion of the GConf library <gconf-list.gnome.org>
>
>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?

> 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 have tried
>to write a constructive answer to your mail, and you replied by posting 
the
>initial problem, which has started the whole discussion. So you will find 
the
>answers in previous mails.

I don't believe there has been an answer to the points above.

Colm.
>- Dietmar





[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]