Re: profile sharing and directory service

Conrad Carlen wrote:

> 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.
>
> 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. 

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)?

Jud