XML archiver

[Bradford Hovinen <hovinen ximian com>]

It was requested that I send a summary to this list detailing the XML
archiver that I have written and how it relates to multisession. So here
it goes...

The XML archiver was originally developed for the Ximian Setup Tools as
a way of storing snapshots of the user's configuration in a database.
The snapshots can then be used in three ways: rolling back to an old
configuration, storing multiple configuration profiles ("location
management"), and remote administration. The design of the Ximian Setup
Tools, with a separation between the front end and the back end, lent
itself very well to this technology. We realized early on, however, that
the same technology could be useful for the capplets in the control
center as well.

We recently starting moving the capplets that will be used by normal
users most frequently to bonobo-conf. For us, this facilitates much
easier and safer debugging of the archiver. For the end user, it
provides additional functionality and logical closure (so that the
functionality I have mentioned is available everywhere in the control
center, rather than just selected places). I wrote a moniker that
accesses this XML archive, using it as a store. This means that, for the
capplets, all of the functionality I mentioned above is made available
simply by using an appropriate moniker to access its configuration (e.g.
"archive:user-archive#archiverdb:background-properties", which resolves
to a Bonobo/ConfigDatabase interface).

There has been some concern about how this interfaces with the session
management work being done. They do not appear to be incompatible. There
is a natural association between the multiple profiles I mentioned above
and multiple sessions. With only a very slight modification to the
moniker I have written, we can support multisession transparently[1]. If
we go that route -- which I strongly suggest we do -- then there is no
need to have a separate "location manager" for the capplets.

I originally wrote this moniker primarily for the capplets, but there is
nothing stopping another developer from making use of the same moniker
to store configuration. Doing so would cause the program's configuration
to be archived in the same manner, and the program would support
multisession transparently. However, the developer would be responsible
for writing his own rollback dialog, as the one I have written is tied
to the capplets. Also, it introduces a dependency on the control center.
Whether to use this is up to the developer.

All of what I have mentioned above should be completely transparent to
the end user. 

As to some specific questions, which I will quote here:

> - what is the user problem or problems we are solving.
>     - saving application state so we can launch/relaunch 
>       a canned session?
>     - laptops that can be docked or undocked?
>     - system administration?
>     - rollbacks? 

The XML archiver deals with, or can handle, items 1 and 4 on this list.
The Ximian Setup Tools (and location management therein) deals with
items 2 and 3.

> - what user problems are we ignoring as Too Hard To Fix?

I know of none.

> - what does the UI look like, including Nautilus, gdm, session
>    manager, control center, sysadmin tool, apps (e.g. gnome-terminal's
>    terminal classes), everything?

I have not thought about that, as I am not a UI developer. However,
whatever UI is developed for multisession should be sufficient, as the
XML archiver can support it transparently.

> - what APIs do apps use and in what way to get things right?

As mentioned above, whether to use the vanilla multisession or the
archiver moniker is up to the developer; the advantages and
disadvantages of that descision are detailed there.

> - how do location management and session management interact. 
>    are the location-specific settings "inside" a session, or 
>    do they span sessions?

In this context location management is nothing more than session
management. A location corresponds with a session -- there is no
difference. So the interaction is trivial.

> - how do location management and session management work with gconf -
>    for example, if I have a setting /apps/nautilus/foo, and I want to
>    store a session-specific or location-specific override for that
>    setting, how do I do that? What if an administrator has locked 
>    down /apps/nautilus/foo so it's not writable; can I still 
>    store a per-session setting for that?

GConf interacts the same with with session management as before. GConf
can interact with the XML archiver as well by writing a new backend, but
that is again up to the developer.

> - what can non-GNOME apps do in order to work properly with our
>    scheme, whatever it is?

Non-GNOME apps should use the session management protocol, as they
cannot use the XML archiver without becomming GNOME apps.

> - for problems we can't solve in the GNOME 2 timeframe, are we
>    leaving a migration path to fix them later, or are we creating a
>    bunch of stored user data that will be hard to migrate? i.e. what
>    is the plan after GNOME 2 to fix remaining issues?

I am not sure I see all of the issues involved here, but I believe
upward migration should be feasible.

[1] One potential issue is that, at present, profiles must be created
explicitly before they are used. I need to do a bit more research on the
session management protocol, in particular how session IDs get
generated, to understand what, if anything, needs to be done to make
that work transparently. It might be necessary to create a mechanism
where profiles are created automatically as soon as there is any attempt
to access them.

-- 
-Bradford Hovinen

We are most probably here for local information-gathering and
local-Universe problem-solving in support of the integrity of
eternally regenerative Universe.

   -- R. Buckminster Fuller