Session management was GNOME is f*cked seven ways from Sunday
Received and responded to in email, posting to the list so others can
add their thoughts, corrections, etc...
If any one knows more about efforts to improve the session management
situation, tell.
On Mon, 14 Feb 2005 14:58:44 +0000
Shaun Lipscombe <shaun.lipscombe@gmsl.co.uk> wrote:
> Just a question if you dont mind..
>
> What is session management?
The X Window System is divided into multiple parts. You have the server
which interacts with the video hardware. You have the font server which
may or may not be located on your machine. And you have the client
which runs the programs. In addition to this there is a growing number
of modules and extensions which you may or may not want to run.
The X Windows System works off of defined sessions that tell it what to
run, which can be configured by changing various configuration files and
scripts.
I think much about sessions and session management is not understood by
most people, myself included so I don't have a simple answer to that
question and maybe there isn't one, but...
If you run Windowmaker as your window manager it provides rudimentary
management of the session by providing a save session menu entry or
optionally the session can be saved whenever you exit. When you save a
session the next time you start Windowmaker everything that was running
when you saved the session will start when you start Windowmaker. Doing
session management this way is pretty straight forward you rely on the
user to decide when to save a session look at what is running then set
it up so all those things start again. On the one hand it is fairly
predictable, but on the other there is no interaction with individual
programs so they can be informed on whether to save information about
their running state. This is not such a big deal for mixers, applets,
etc... that save their state independently of any session management,
but for the email program, the word processor, etc... that do not
normally save information about their state or that save backup
information at timed intervals, there is a desire for something more.
Gnome and KDE try to be more intelligent. They provide daemons for
session management. If a program is session aware it will see this
daemon or the daemon will see it and they will be able to interact with
each other. If the Gnome apps can't interact with the KDE session
manager and the KDE apps can't interact with the Gnome session manager,
then session management can not be fully realized. One would hope that
standards for session management would be created that are independent
of Gnome or KDE.
With this extra intelligence comes extra complexity. Gnome and KDE give
you ways to deal with this complexity. In Gnome from the control panel
or from the menu you can starts the session management configuration
utility to configure what should be managed and how it should be
managed. In KDE you have a configuration file you can edit to define
these same things. In both cases it is an unintuitive process that can
result in quirky behaviour.
I expect most people probably don't know about session management, don't
care about session management, don't understand how it can benefit them,
and just want a simple way to choose what gets started when they start
their X session. This in and of it's self is not a problem as the
session management daemons should do their thing in the background
without the user having to be aware of what it is, what it does, etc...
If session management is fully realized it has the potential to easily
take care of all these things for the user based on choices they make
within whatever GUI they happen to be running.
To fully understand the potential of session management think of a
couple of hypothetical situations.
Situation one:
You have you computer at home, at the office, where ever, hooked to a
UPS so if the power fails it runs from the battery and all is not
immediately lost. Eventually the battery gets low and the UPS signals
the machine that it should shut down to protect it's self.
In a non session managed environment the programs you had running at the
time will not get started again and when you start them your self they
may not remember what they were doing when you last had them open.
In situation two:
Immagine that same machine hooked to a UPS and say you were working in a
word processor or report writer creating a report and a spreadsheet to
provide information for that report. While doing this an email comes in
so you look at it and decide you want to respond to it right away. Half
way through the email you get a phone call and have to leave, so you
leave all these works in progress open partly done. While you are gone
the power fails, the battery gets low, and the machine receives the
signal that it should shut down to protect it's self.
If the potential of session management is fully realized. When the
machine receives that signal to shutdown the session manager will save a
list of everything that is running so those things can be started again
and communicate with the running programs so the state of the individual
programs can be saved and returned to when they are started again.
So now when you come back to the machine and find it powered off. You
start it. Log in and up come all the programs you had running. The word
processor or report writer with the same file open at the same location
in the file. The spreadsheet open ready to continue where you left off.
And the same for the partially written email message.
seeker@magicbus:~/Documets$ vim What_Is_Session_Management.txt
seeker@magicbus:~/Documets$ cat What_Is_Session_Management.txt
On Mon, 14 Feb 2005 14:58:44 +0000
Shaun Lipscombe <shaun.lipscombe@gmsl.co.uk> wrote:
> Just a question if you dont mind..
>
> What is session management?
I think much about sessions and session management is not understood by
most people, myself included so I don't have a simple answer to that
question and maybe there isn't one, but...
The X Window System is divided into multiple parts. You have the server
which interacts with the video hardware. You have the font server which
which may or may not be located on your machine. And you have the client
which runs the programs. In addition to this there is a growing number
of modules and extensions which you may or may not want to run.
So at the very lower level you have various scripts and configuration
files that can be editied to define what should or should not run as
aprt of a basic session when you start the X Window System by typing
startx or rstart to start a local or remote session or log in using a
display manager such as KDM, GDM, XDM, etc...
This is all very rudimentary and your window manager or desktop
environment provides additional session options on top of this either
through a configuration file, a utility, daemon, or any combination of
these things.
If you run Windowmaker as your window manager it provides management
options to save a session manually from a menu entry or optionally you
can choose for the session to be saved automatically whenever you exit.
When you save a session the next time you start Windowmaker everything
that was running will start when you start Windowmaker. Doing session
management this way is pretty straight forward you rely on the user to
decide when to save a session look at what is running then set it up so
all those things start again. On the one hand this is fairly basic and
predictable, but on the other there is no interaction with individual
programs so they can be informed on whether to save information about
their running state. This is not such a big deal for mixers, applets,
etc... that save their state independently of any session management,
but for the email program, the word processor, etc... that do not
normally save information about their state or that save backup
information at timed intervals, there is a desire for something more.
Gnome and KDE try to be more intelligent. They provide daemons for
session management. If a program is session aware it will see this
daemon or the daemon will see it and they will be able to interact with
each other. If the Gnome apps can't interact with the KDE session
manager and the KDE apps can't interact with the Gnome session manager,
then session management can not be fully realized. One would hope that
standards for session management would be created that are independent
of Gnome or KDE, which I think is slowly happening but is a work in
progress.
With this extra intelligence comes extra complexity. Gnome and KDE give
you ways to deal with this complexity. In Gnome from the control panel
or from the menu you can starts the session management configuration
utility to configure what should be managed and how it should be
managed. In KDE you have a configuration file you can edit to define
these same things. In both cases it is an unintuitive process that can
result in quirky behaviour.
I expect most people probably don't know about session management, don't
care about session management, don't understand how it can benefit them,
and just want a simple way to choose what gets started when they start
their X session. This in and of it's self is not a problem as the
session management daemons should do their thing in the background
without the user having to be aware of what it is, what it does, etc...
If session management is fully realized it has the potential to easily
take care of all these things for the user based on choices they make
within whatever GUI they happen to be running.
To fully understand the potential of session management think of a
couple of hypothetical situations.
Situation one:
You have you computer at home, at the office, where ever, hooked to a
UPS so if the power fails it runs from the battery and all is not
immediately lost. Eventually the battery gets low and the UPS signals
the machine that it should shut down to protect it's self.
In a non session managed environment the programs you had running at the
time will not get started again and when you start them your self they
may not remember what they were doing when you last had them open.
In situation two:
Immagine that same machine hooked to a UPS and say you were working in a
word processor or report writer creating a report and a spreadsheet to
provide information for that report. While doing this an email comes in
so you look at it and decide you want to respond to it right away. Half
way through the email you get a phone call and have to leave, so you
leave all these works in progress open partly done. While you are gone
the power fails, the battery gets low, and the machine receives the
signal that it should shut down to protect it's self.
If the potential of session management is fully realized. When the
machine receives that signal to shutdown the session manager will save a
list of everything that is running so those things can be started again
and communicate with the running programs so the state of the individual
programs can be saved and returned to when they are started again.
So now when you come back to the machine and find it powered off. You
start it. Log in and up come all the programs you had running. The word
processor or report writer with the same file open at the same location
in the file. The spreadsheet open ready to continue where you left off.
And the same for the partially written email message.
It seems at the lower level progress is being made so the scripts and
files that provide the basic session configuration for the X Windows
System are done in a more uniform fashion and session
configuration/management utilities can look at them and say 'I know how
to handle that' without each one having to provided it's own files and
scripts for every little part that it wants to handle it's self, but
while there has been progress we are not fully there yet. At the higher
level where you have session management daemons and session aware
programs I don't know what if anything is being done to create standards
for the applications and daemons to interact with each other.
To be fair to developers, reaching my hypothetical fully realized case
is not an easy thing. If my understanding is current and correct, there
are not many developers willing to tackle updating of session management
and fewer (maybe none) that have a good grasp of where things are
currently and what direction to go next. As a result of this
improvements are marginal with the bulk of the effort going towards
keeping the session managers syncronized with the rest of their
respective desktop environments and to keep from screwing them up,
because if session management gets screwed up the impact is felt in a
big way if the session manager crashes and takes your running
applications with it and potentially your entire X session or in more
subtle ways if individual applications crash when they try to interact
with the session manager.
Later, Seeker
Reply to: