Re: profile sharing and directory service

Conrad Carlen <[email protected]> writes:
> See http://www.mozilla.org/projects/embedding/shared_profiles.html for 
> background on the problem.

Something that isn't really mentioned there is roaming, which we're
going to need to support sooner or later.  While the first-cut at this
is likely to be 4.x style roaming (download profile info at the
beginning of the session; re-upload at the end), the ultimate goal
would be to allow for single pieces of data to be read/written from
the server at run-time (with a write-through cache mechanism,
perhaps).  Any chance you could add something along these lines to
this document?

> One issue here is that some data my be desirable to share within a given 
> profile and some may not. As an example of data that is not, much of 
> what's stored in localstore.rdf (window state) is not. The necko cache 
> is another, but for a different reason - it's difficult to implement 
> sharing of the cache in the first pass at this ;-) Until this problem is 
> overcome, the Cache dir would not be shared.

Roaming introduces another variant of this: you're likely to want to
share some things (eg cache, once that is possible) locally but not
remotely.  This can probably be easily dealt with just with an
additional LOCAL | REMOTE bit.

> Consumers of profile data get their file locations through directory 
> service. The provider for the profile-relative data is the profile mgr. 
> There needs to be a way for a consumer of a file location to get a file 
> location specific to its private partition of a profile. One possibility 
> is this: If the directory service key was prefixed by a proc ID string 
> (constant always for that app), say "%Proc:ProgramX%", directory service 
> could separate the given string into the proc ID and the location key. 
> Given these two pieces of data, directory service could QI to (yet 
> another, sorry) nsIDirectoryServiceProvider iface. That provider would 
> return the location for that given app's file or directory.

Home directories are often on remote-filesystems, so I think we'd do
better to use an IP-address/proc-id tuple than by using proc-id alone.
This is what the current UNIX profile-locking code does.

Dan