Judson Valeski wrote: > 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?
Say a profile has non-shared parts which are used amongst 5 different apps. Directory service has to know which non-shared location is the right one when asked for a file location. This could happen in two ways (that I see): 1. The application could just identify itself at the beginning of the session. Then, the directory service provider (the profile mgr), when asked for a location, would know whether this particular location was shared or non-shared and, if non-shared, where to find this file. 2. The consumer could just explicitly ask for a non-shared location, using the %ProcID% method I mentioned. This way, components have to specify whether they use shared or non-shared data. I think that localizes the control over what's shared to the component which uses the data. Say that we are able to make the cache function with shared data. Then we just change what location property *it* uses. > >> 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)? No, consumers never see providers, only the service. If they want to get data from the non-shared domain, they prefix the location property with the procID string. If they want shared data, no prefixing of the location property. Also, I don't think we need a special class of provider to deal with this. A provider could just parse the procID string out of the property -Conrad > > > Jud
