Re: Migration Paths for New Modules

[Brian Nitz <Brian Nitz Sun COM>]

Shaun McCance wrote:
> On Thu, 2006-07-20 at 13:52 -0500, Shaun McCance wrote:
>   
> > Yikes, all right.  We should definitely keep the exec_ats key
> > for legacy.  I suppose the Assistive Technology Preferences
> > dialog should continue to set the old values, if possible,
> > to keep older machines functioning the same.
> >
> > I'm not sure what keys are used by the Preferred Applications
> > dialog.  The keys under /desktop/gnome/applications seem to be
> > obsolete.  We could just make six keys: a boolean to enable
> > each technology, and an exec string for each technology.
> >
> > Then there's the question of the interface.  Would we want to
> > shunt stuff off to the Preferred Applications dialog?  I think
> > it will be more obvious if it's right in the Assistive Technology
> > Preferences dialog.  So something like
> >     
>
> I meant to say something else here, but forgot about it.
> What happens if I set my preferred screen reader to Orca
> on a fancy new machine, and then try to log into an older
> Gnome using the same home directory.  We don't have any
> sort of fallback mechanism in place.
>
> This problem isn't unique to us, by the way, and it goes as
> far back as networked Unix itself.  Changing your shell, for
> example, can be a real headache on a heterogeneous network
> with centrally-managed login information.  You won't even be
> able to log into a machine without your selected shell.
>
> I don't necessarily have a good solution to this problem.
> I can think of some strategies, but none that I think are
> much more than a hack.
>
> I know there's been blue-sky talk of a next-generation
> configuration system.  A general-purpose solution to
> problems like these would be a definite selling point
> for such a system.
>
> --
> Shaun
>
>
> _______________________________________________
> desktop-devel-list mailing list
> desktop-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/desktop-devel-list
>   
This is one of my biggest headaches in supporting enterprise GNOME 
users.  Consider these use cases:

1.    An ISV creates creates a custom application and wisely chooses to 
base this application on GNOME components which won't change between 
releases.  He creates a launcher for this application in the main menu.  
The launcher stops working when GNOME is upgraded.  Not a huge problem 
for a developer on his laptop, a major headache for a sysadmin of 5,000 
desktops.

2.    Someone logs into a server running GNOME 2.1X, logs out and logs 
into a server running GNOME 2.1.X+2 using the same NFS home directory.

3.    Someone logs into a server running GNOME 2.1.X, _doesn't_ log out 
and logs into a server running GNOME 2.1.X+2 using the same NFS home 
directory.  (This can be common on Sun Ray and possibly other thin 
client GNOMEs)

Should we say that cases 1-3 won't be supported by GNOME?   or...

A simple but incomplete and probably slow solution (hack?) might be to 
put the entire home directory under CVS control or on top of a 
versioning filesystem and give gdm and gnome session the smarts to 
checkout the right branch during login.

Would something like this work instead?:

Move everything off the filesystem into the filesystem independent 
configuration database.  (this includes .gaim, .evolution, 
.gimp,.mozilla, font stuff, desktop files... which means the 
configuration database shouldn't be slower than the filesystem.)

The configuration system manages configuration objects which expose 
read/write methods based on release, key and migration rules.  E.G.

Key                          :Range    :Rule
default_screenreader:2.10-2.14:RW
default_screenreader:2.06-2.14:R
default_screenreader:2.16-2.20:M

The M rule means the migrate methods would be called for releases where 
Read or Write are not already defined in the rules. 
These methods would take key, version_key and version_now.  In this 
case, the migrate read method would decide that if default_screenreader 
GNOME 2.12 key value is "gnopernicus", and the client is version 2.16, 
it returns "orca".

Yeah, I know this idea is only 25% baked, but could it be refined into 
something which would improve the user experience?