Re: GConf and bonobo-conf
- From: Colm Smyth <Colm Smyth ireland sun com>
- To: Colm Smyth ireland sun com, dietmar ximian com
- Cc: hp redhat com, gconf-list gnome org, gnome-hackers gnome org
- Subject: Re: GConf and bonobo-conf
- Date: Tue, 20 Feb 2001 14:09:33 +0000 (GMT)
>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 ireland sun com>
>Cc: hp redhat com, gconf-list gnome org, gnome-hackers gnome org
>Subject: Re: GConf and bonobo-conf
>Content-Transfer-Encoding: 7bit
>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:
>
>> Bonobo-conf can naturally read and write any CORBA_Any because it
>> doesn't care about type or content. If GNOME applications can write
>> version-dependent binary information into GConf, users will have a lot
>> of difficulty upgrading. Since GNOME development is fast and we want
>> to keep adding new features, we don't want to be stuck with
>> version-compatibility issues, or worse we don't want to write specific
>> code to migrate users from one application version to the next!
>>
>> It also means that the data is unreadable by other applications
>> unless they use the same data-structure (and the same version).
>
>Ok, once again: The goal of bonobo-conf is not to store everything
>as binary data. If you restrict yourself to the basic types used by
>GConf the values are even stored in the native GConf format - no
>binary data at all ;-)
I can see that you feel you are repeating yourself, so do I!
It seems that you're saying that if developers don't use any of the
features of bonobo-conf, they won't have problems. I agree.
>> If you write configuration data as primitive values, you get the
>> following advantages:
>>
>> - application transparency; other applications can easily read and
>> write the data
>
>read/write is not problem, even if you use CORBA_any. The real
>problem is if you want to modify values. We have PropertyEditors
>for that.
I'll take a wild guess and assume that a PropertyEditor is a
Bonobo component that displays a GUI for editing GConf data.
Unless my application is Bonobo-based, I can't use your PropertyEditor
interface. Read/write is only useful if an application can interpret
the data.
>> - easier upgrade; most changes to data structures are additions and
>> this creates no upgrade problems as new applications can continue
>> to read the existing configuration information
>
>> - easy to edit; users will be able to use the GConf tools to change values;
>> gconftool can display and edit values, and the upcoming Gtk+-based
gconfedit
>> application will also be able to browse, display and edit GConf.
>
>I think "PropertyEditors" as used in bonobo-conf are better and even
>easier to use.
You're assuming that all an application wants to do with configuration
data is to display a GUI to edit it. What if my application needs to
understand the configuration data (to transcode, convert, upgrade,
import, export, or modify programmatically) ?
Colm.
>- Dietmar
>
>
>
>_______________________________________________
>gconf-list mailing list
>gconf-list gnome org
>http://mail.gnome.org/mailman/listinfo/gconf-list
_______________________________________________
gnome-hackers mailing list
gnome-hackers gnome org
http://mail.gnome.org/mailman/listinfo/gnome-hackers
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]