Profile Sharing (2.0?)

Christopher Blizzard

Note: this should not be confused with the Profile Sharing page that deals with sharing the same profile between applications on the same machine. However, you should read that since it's relevant to this discussion as well.

Overview

One of the problems that has plagued personal users and sysadmins alike is the ability to save profile-related resources in the web browser in such a way as you can access them at the same time and keep them updated from multiple locations. In the Netscape 4.x days roaming profiles which allowed you to upload your bookmarks and various preferences to a server using HTTP or LDAP allowed for some of this functionality. This functionality is now in our tree, but it's very similar to the way that 4.x worked - that is, uploading and downloading blobs with time stamps.

This living document includes throughts on what we might possibly do in the future to support some more advanced methods for sharing preferences and user-profile related resources in Mozilla.

Goals

Anything that we build should probably include at least the following goals (each will be discussed):

1. Preferences should integrate well with an existing operating system mechanism, if it exists.

It's important that our preferences system should use an operating system mechanism for storing those preferences, if possible. We want to make it possible for Mozilla to be configured with defaults that are configured via tools that are not specific to Mozilla. That is, you need to be able to configure Mozilla as part of an entire desktop system from the same point using the same tools as the rest of the desktop.

• Do you mean mmc integrating under Win2K+?

2. The mechanisms for saving data should be hidden behind APIs so it's possible to replace backends easily.

This is both because of cross-platform concerns and also because we want to be able to isolate the backend. We've got working preferences right now and I don't think that anyone wants to break the existing tools and require the use of new tools that might not be available in all places.

3. No system should be dependent on network availibility. That is, if the network is not there the app will continue to operate on a backup or cached copy of the data.

Brendan brings this up and I think it's important to note explicitly. It's important that whatever we use has a local cache of network preferences and can operate in a disconnected state.

• Not only on cache, but before any connection after installation we should work too. So we need reasonable defaults.

Integration Points

There are quite a few places that need integration in profiles. These include, but are not limited to:

• Preferences (as in nsIPref)
• State Information (as in localstore.rdf)
• Certificates
• Address book
• Keyring
• Bookmarks
• Cookies
• History
• Mime Type Bindings
• Mail Filters
• Mail Folder Preferences

There's a large assortment of items here that need to be handled. Note that we have lists, blobs and trees to deal with in this list. The current profile plan just handles access to the underlying files that hold the data, however I would suggest that in the profile case for sharing across muliple machines and architectures, that we move to a transaction model where possible. That is, if you update a pref you should be able to get an update for that change only, not change the entire blob that preferences are currently stored in.

It would be nice to be able to do this with things like bookmarks and other rdf-based resources as well. This might require a huge rdf-based remote api that does this, though, and that's kinda scary. Not impossible, but still scary.

Some quick and dirty ideas on how to implement this quickly on Linux:

• Map nsIPref to GConf. This shouldn't be too hard. It maps well.
• Make it possible to save bookmarks and other rdf-related items as blobs on an LDAP or other store. 4.x had dialogs with timestamps - we could do the same.
• Things that are lists or don't require depth could be easily moved to GConf. i.e. certificates. Maybe cookies as well.
• Items like addressbook probably need to integrate with the general addressbook on the system. i.e. talking to evolution or something along those lines? LDAP is a pretty good mapping for addressbooks.
• Mime types are usually there on the system anyway, so we might not even need to save local preferences. However, people will want to configure this so putting it in gconf or something along those lines might not be a bad idea.

It would probably be worthwhile to check out UniConf and the discussion about it on the freedesktop.org mailinglinglist in relation to DConf.