One issue here is that some data my be desirable to share within a given profile and some may not.Some underlying assumptions we're making at this point AFAICT:
- profiles are not logically shared in a system wide global area, rather there's a "group" of applications (likely related) that designate a well known (among that set of apps) location for their sharable profiles.
- shared vs. non-shared profile data is at the _app_ level versus global
to a MRE. Conrad's example of window position/size state in localstore.rdf
is a perfect example of why there is some data that is app specific.
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.let's use the terms "non-shared" and "shared" versus "private" and "public." The latter terms introduced concepts that get confusing in this context IMO.
What motivates this need you're talking about? The ability for an app to override shared profile data?
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.Are you saying that there would be a nsISharedDirSvcProvider, and a nsINonSharedDirSvcProvider that the app would have to juggle (determine when it wanted to access which)?
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.
Jud
