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
