how to store prefs/session data

[Havoc Pennington <hp redhat com>]

Hi,

Appended is an earlier mail outlining the issues of prefs/session
data. This mail is what I think we should do, as a proposal.

 A. Only settings related to window sizes/positions, application 
    _instance_ state (e.g. currently open document), 
    and display size, should be stored per-session. 

    Rationale: the session is a canned setup for a particular 
    display or task. It is not a canned set of preferences; 
    preferences span application instances.

 B. These settings should NOT be stored globally, at all. i.e. for a
    given setting, it is either global or per-session. This implies
    for example that when using bonobo-config, you would have 
    one property bag for global settings, and one for per-session, 
    and you would not ever interchange those property bags.

    Rationale: it just doesn't make sense to mix the session 
    state with user preferences. This would seem obvious but
    some apps seem to miss it. You CANNOT implement saving 
    the session by pushing a different config prefix onto 
    your standard prefs-saving code.

 C. There is nothing wrong with storing per-session state in flat 
    files or whatever rather than gconf.

    Rationale: this state is per-application-instance, and there is no
    reason it has to be process-transparent in many cases. Also, the
    per-session state does not make sense for sysadmins to fool with,
    and there is not really much point in attaching schemas to it.
    (Why would a sysadmin change the current positions of your
    windows, for example? If a sysadmin might want to change a
    setting, that's a good indication it should NOT be per-session.
    Users should not lose important/critical settings by changing
    session, they should only lose the state of the windows in that
    session.)

 D. However it may be useful to store session info in gconf, 
    for example for apps made up of multiple processes, or 
    whatever. If you save session data in gconf, it's encouraged to
    do so in a directory called 
     /apps/appname/sessions/escaped_session_id
    where escaped_session_id is a session ID converted to 
    a valid GConf key. Then DiscardCommand should be set 
    to "gconftool --recursive-delete
    /apps/appname/sessions/escaped_session_id"

    I need to add a key-escaper function and --recursive-delete
    to GConf, I'll do that.

    Rationale: the standard "sessions" subdir containing session IDs
    will keep things simple and help people browsing the GConf 
    database quickly understand what that data is used for. 
    Also, storing everything under one dir makes the DiscardCommand 
    easy.

 E. Preferences should be stored in the usual place in GConf, 
    under /apps/appname, and be global.

 F. For per-session state used by multiple apps, I suggest we
    extend the SM protocol to have a session ID for the entire 
    session, in addition to one for each app instance. Then, 
    we add a function to gnome-client to get this ID.

    For the desktop background, assuming that is a per-session
    setting, we would then save at the key:
      /desktop/gnome/sessions/escaped_global_session_id/background

    Rationale: seems like the obvious way to address this issue, 
    and should not be difficult to implement.

 G. The rollback/archiver feature should only apply to preferences, 
    not to saved session state. For example, if we decide the
    background is per-session (I'm not sure it should be), then 
    it would not do rollback.

    Rationale: the intersection of rollback and sessions is just too 
    complicated, and it doesn't make any sense anyway. Restoring 
    the positions of your windows on Friday is not interesting.

So, this involves two API additions (gconf_escape_key() and
gnome_client_get_global_session_id()), plus one gconftool feature
(--recursive-delete).

Comments?

Havoc

Earlier mail - 

Things users might want to do
===
 
 (pure speculation)

 - have state specific to a display (monitor/mouse/keyboard
   combination, i.e. typically a single physical computer)
 - explicitly create a set of apps that normally launch when they log
   in
 - have these apps they saved come up at a specific size/position 
 - be able to log out, and log in again, automatically/implicitly
   restoring the apps they had open on logout
 - have apps restore their size/position each time they are launched,
   a la MacOS (different from restoring size/pos of a particular
   instance, as with session management)
 - temporarily log out, let someone else log in, then go back 
   to their session (as with Windows XP)

A sampling of preferences, settings, state, whatever
===

panel - 
  - animation speed for hiding
  - tile style
  - size of icons in menus
  - menu contents
  - keybindings
 
properties of specific panels - 
  - panel type
  - size
 
nautilus - 
  - icon/list view
  - fonts to use 
  - open files in new window vs same window
  - window contents (toolbar, sidebar)
  - manage the desktop
  - single vs. double click
  - home URL
  - search engine URL
  - news panels

gedit - 
  - show statusbar
  - toolbar style
  - font, colors
  - print setup (word wrap, banner, line numbers, paper size)

generic properties of any app's current state - 
  - number and type of open windows
  - window size/position 
  - window desktop
  - documents opened in each window

desktop-wide preferences/state - 
  - theme
  - background/wallpaper
  - default font
  - mouse acceleration
  - key repeat rate
  - screensaver
  - favorites/bookmarks
  - recently-used documents

Current infrastructure
===

Session management: we have a unique identifier for each application
instance, which allows apps to save per-instance state. Also, a
mechanism for window managers to save application window state.  Could
trivially add an ID for a global named session, allowing us to save
per-session state. (But importantly, in the current codebase, you
can't store per-session state; only
per-instance-of-an-app-that-is-in-a-session state. A subtle
distinction, but it means that currently a global setting like
background color can't be per-session. We'd need a trivial SM protocol
extension for this.)

GConf: Stores preferences in a global process-transparent way.

gnome_config_*: Stores simple text files.

bonobo-config: stores key-value pairs in a variety of locations
including GConf or text files.

Archiver: stores XML files with date-stamped dumps of current state,
and can stuff the snapshot from any date back into the config
system. (right?)

Questions
===

What do users really want to do?

What should the UI for doing that look like?

How do we reliably and consistently implement it across the desktop?

How do we do this while still providing the admin benefits of GConf?

Can we divide the list of sample prefs/state given above into some
sort of categories? Do we treat some of them differently?

Did we answer any of the above questions with something overengineered
or overcomplicated?