Technology Specification for Shared Profile Data
author: jgaunt date: Sept 19, 2002
Summary
Outline the requirements for profile sharing, define some terms for this conversation and outline the approach being taken in general terms. For more discussion of what areas are impacted by profile sharing see this profile sharing document. For more technical documents dealing with implementation specifics for the different components head to the profile sharing tech doc homepage.
Definitions - for this discussion
- user - in the terms of multiple login machines this equates
to the concept of an Operating System user, defined by the login to the
system.
- process - a gecko based program that access the profile of a user
- server - a process separate from the gecko process, launched by a gecko process to manage communication between gecko processes
- client - equivalent to "process" above
- profile - a single user may have multiple profiles on a system. This refers to one of those profiles. The profile stores user specific data for an installation of gecko
- shared - data in a user's profile that can be viewed and changed by more than one process
- non shared - data in a user's profile that a specific process
declares it does not want to share with other processes
Requirements
For a single user profile, allow multiple gecko based processes to share profile data at runtime.
- Allow multiple processes on a single computer access to a single user's profile data at runtime, dynamically
- Do not lose any changes to the profile data -- zero corruption!
- When a process starts up make sure it has the most current set of shared profile information available at the moment it starts up
- Allow processes to not use the shared profile system at all and be able to run in a non shared profile environment without incurring any overhead ( or at least minimal )
- Co-ordinate with all the subsystems using profile data to avoid breaking of features ( i.e.. locking of prefs, time-out of cookies... )
- No corruption of profile data EVEN in the face of process/manager
hangs or crashes (some kind of backup system?)
Design
- The overriding goal of this design is to impact the existing systems as little as possible. This functionality should "bolt-on" to the side of the existing profile implementations. This approach should keep to a minimum code bloat in builds that do not have a shared profile environment (i.e. WinCE). There will be some general profile work that will need to happen, but the individual components ( i.e. cookeis, prefs, cache, etc... ) should not need to be overhauled to make use of this system.
- 50k foot view - profiles will be split into shared and non shared spaces. Individual processes will have a non shared directory for data they do not want to share with other processes and they will be able to access a shared folder (most likely the root profile folder where everything is currently stored) to get access to any shared data. When making changes to shared data a process will notify the Transaction Manager (TM) of the change and the manager will broadcast a message to any interested processes. Upon receiving a message from the TM a process will modify its internal state to correspond with the known state of the shared data.
- Seperate locations for storing shared and non-shared data
- For programs that need some non-shared space, give them an individual folder within the users profile directory ( {USER_DIR}/{salted name}/[phoenix|mozilla|netscape|chimera|etc] ). This directory will almost always be needed as there will be chrome files etc that won't be shared
- in the base level of the user's profile directory ( {USER_DIR}/{salted name}/ ) keep the data that will be shared - shared pref files, cookies etc...
- The seperate TM process will be launched on startup of the first gecko
based process and subsequent gecko processes will register with the existing
TM.
- The TM will be run out of process and communicate via an IPC mechanism. It will coordinate the messaging aspect of profile sharing, namely it will receive from a process a message describing a change to the profile data. That message will then be relayed to all processes who have registered as a listener for the profile subsystem that is being modified. Only a system interested in the specific change will be notified of that change. Processes registered to listen for preference changes will not get messages about cookie changes.
- The IPC mechanism will be as cross platform as possible. It is understood that we don't currently have a completely cross platform way of doing IPC, so platform specific implementations may be necessary. If it is possible to formulate an API (ala NSPR) that does cross platform IPC such an API will be created.
Use Cases
- Startup - on startup a process will have to check for the existence of a TM. If it does not exist, and the particular platform allows sharing of profile data (might be application specific too) the TM will be started and the process will register with the TM as a process that has the capability of being interested in shared data. The process won't actually register as a listener of shared data until the actual modules that use the shared data are started up. Hopefully this will keep race conditions and startup ordering issues to a minimum.
- Shutdown - at shutdown a process will need to remove itself from any shared data listener list in the TM that is has been added to. The process will need to make sure it's data is up to date first, and then write that data out to disk. After all of this it will need to check if any other gecko processes are registered with the TM, and if not, then it will shut down the TM (perhaps in the case of the quickstart feature we need to handle something special here - quickstart could throw some funky variations on the shutdown/startup patterns)
- Writing data to disk - We write profile data to disk periodically through
the runtime of the application. Sometimes they are timer based, sometimes
UI driven. The key with shared profiles is to make sure whatever gets written
to disk is the most up to date information available. So before each write,
a process needs to check the TM for transactions in the queue that haven't
been processed.