Re: GConf and bonobo-conf

["John R. Sheets" <dusk ravendusk org>]

On Feb 16, 2001, Dietmar Maurer <dietmar ximian com> wrote:
> 
> Anyway, you always have a problem if you change the type (=content)
> of the data stored in the database, and you need to define a smart upgrade
> path - even if you decompose the values as suggested.

...

> struct Color {
>     int r,g,b;
> }
> 
> We then decide to store them as:
> 
> struct Color {
>     int c,m,y,k;
> }

Naturally you'll have problems if you make changes to your data types
that are not backward compatible.  In that case, you'd want to use a
new config key, e.g., ColorCMYK.  However, there's also the case where
you maintain backward compatibility, but _extend_ the data type:

struct Color {
    int r,g,b;
    char *name;
}

With an older client, you'd still want to be able to get the R/G/B
value, but if the client is newer, you'd like to be able to ask for
the new 'name' field as well.  If the data types are serialized in a
binary format (or whatever), you'll lose this robustness, and end up
having to duplicate the Color data in a new key, e.g., Color2, or
ColorWithName.

> So what is the advantage of decomposition in that case? The upgrade
> problem always exists.

Right, but the difference is that one way you break older clients, and
the other way you don't.  (c:

John

-- 
dusk ravendusk org                            http://www.gnome.org
jsheets codeweavers com                  http://www.worldforge.org
jsheets users sourceforge net     http://openbooks.sourceforge.net
               http://advogato.org/person/jsheets

                   Writing Gnome Applications
          http://www.aw.com/cseng/titles/0-201-65791-0/

_______________________________________________
gnome-hackers mailing list
gnome-hackers gnome org
http://mail.gnome.org/mailman/listinfo/gnome-hackers