Re: prefs storage plan

[Havoc Pennington <hp redhat com>]

Maciej Stachowiak <mjs noisehavoc org> writes: 
> Do you have a shorter executive summary? I'll try to read the full
> version as time permits but I suspect others won't.

Sure, but the short version doesn't have rationale or definitions, so
no one can comment on it without asking a question I already
answered. ;-) It's 260 lines, you're just a wuss.

Here are some highlights.

 Data can be namespaced in the following ways:

   - by including the application session ID in the data key, 
     the saved data will only apply to one copy of an app

   - by including the desktop session ID in the data key, the saved
     data will only apply to app instances that are in the session
     with that ID

   - by including no session ID in a data key, the saved data will 
     apply to all app instances in all sessions


  . Only settings related to application _instance_ state should be
    stored under the application's session ID. Examples are the
    currently-open windows, what documents are opened in the windows,
    where the cursor is located. Most settings are global preferences, 
    not session state.

  . Important or critical data, including preferences that take effort
    to set up, should never be stored per-session.

  . User preferences should almost always apply globally to all app
    instances in all sessions. With GConf this can happen without 
    even restarting the app instances.

  . Settings that are per-session, but not associated with a
    particular application instance, should go under the desktop
    session ID.

  . In no case should the same setting be stored both per-instance and
    globally.

  . Per-session settings should not appear in any prefs dialogs.

  Also:

   Apps should use a "profiles" concept when you want lots of state 
   stored per-session.

  [Omitting all info on how to implement using our libraries]

Now, I expect that made no sense, because it has no explanation, but
it was short. ;-)

Havoc