prevent data loss in running activities

[Tomeu Vizoso]

Hi,

as tracked in tickets #4088 and #6014, there are two situations where
the user can loose data inadvertently:

- user shutdowns from the system menu,

- laptop shutdowns unexpectedly because the laptop runs out of power or
the user pressed the power button.

Most activities are saving their state in the background when the user
switches to another activity, so in most cases the data loss will be
limited to the current active activity, since the last explicit or
implicit save. But this is probably not enough, as exposed by the
reporter of #6014.

In order for activities to save their state before the system cleanly
shuts down, we could use XSMP. We really don't need all that is in that
spec, specially the stuff about local and global state (our state is
always global).

http://www.xfree86.org/current/xsmp.pdf

We would need a session manager that synchronizes how clients save their
state and exit cleanly before the shutdown happen. That session manager,
be in its own process, matchbox (if there is already one in there) or
the sugar shell.

We could use an existing implementation of XSMP like gnome-session, but
people seem to agree in that its code is horrible and a complete
replacement is needed.

http://svn.gnome.org/viewvc/gnome-session

Follow two tentatives at rewriting gnome-session:

http://svn.gnome.org/viewvc/gnome-session-manager
http://svn.gnome.org/viewvc/msm

Also, there has been some discussion in freedekstop lists about ditching
XSMP and establishing a new standard based on D-Bus.

Has been suggested at some point that activities save before suspend. Is
this really needed? Do we want to make longer the time we need for
suspending? If OHM would wake up when the battery reaches a critical
level in order to initiate a clean shutdown, then we wouldn't need to
consider this as an special case.

Summarizing, I see three possibilities:

- Adopt a full-fledged implementation of XSMP and ask activities to
support just the save-on-shutdown part of it. (Giving a nice wrapper at
least for python activities).

- Implement a subset of XSMP in a new session manager implementation.

- Add a couple of D-Bus methods and signals to OHM/HAL, the sugar shell
and the activity service enough to support what we need.

Note that I'm talking about the short term here. What we should aim for
given the scarce resources we have, not what we ideally would do.

Comments?

Thanks,

Tomeu