See http://www.mozilla.org/projects/embedding/shared_profiles.html for background on the problem.
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. 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. Yes, it's unfortunate to have another type of nsIDirectoryServiceProvider but, on the other hand, it would allow partitioning of profile date into shared and private data with minimal change to directory service consumers. Feedback? -Conrad
