Re: The future of session management in GNOME

[Bryan Clark <bclark redhat com>]

Bastien Nocera wrote:
> On Mon, 2006-09-11 at 11:35 +0200, Rodrigo Moya wrote:
>   
> > On Thu, 2006-09-07 at 00:25 -0400, Havoc Pennington wrote:
> >     
> > > I do think the XSMP state-saving model is absurd and should be ignored, 
> > > however, even if XSMP is used for logout notification.
> > >
> > >       
> > yeah, I would even completely remove the state saving thing :-)
> >
> > In fact, how many GNOME apps do the state-saving correctly (whatever
> > that means)?
> >     
>
> I know quite a few that do, and I spent a lot of time adding the
> feature, and fixing it in Totem. I don't think that removing it would be
> a good idea, unless there is a way to recycle that feature into an
> application-specific state saving.
I think it makes the most sense to do this on the application level and 
perhaps there's some kind of shared code that different applications 
could use to do this.  If I remember correctly Evince looked at Gedit in 
order to get an idea of how the state saving system was used such that 
the page, zoom level and other properties could be kept. 

Keeping application state really makes the most sense to be done at the 
time you're interacting with the application.  If you've edited a file 
just a bit and then forgot it in another workspace for a while, by the 
time you log out you'll have to recall exactly what you did to that file 
in order to make the correct choice of save / don't save.  It's much 
better to keep the context of the situation when asking a question like 
that, or even better if you don't ask that kind of question.  The 
problem isn't so simple, but it's a problem all of us deal with so we 
might as well try to fix it at least for ourselves.

In order to keep state properly in this manner a lot of applications 
that weren't originally designed to do this have to change how they 
interact and work.  Often this is when architecture astronauts propose 
the database file system or RCS file system, and sure that could help 
the problem in some ways but you're also introducing new issues while 
still having to deal with the same situations as before.  I would take a 
simple start by looking at how each application could keep it's state in 
a way that makes the most sense and form a common library around the 
applications that are doing this.  Once we have this initial concept 
ironed out a bit we could move on to bigger and better ways of solving 
the problem later.

~ Bryan