Conrad Carlen wrote: > 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.
I am missing what you would have to the directory service would have to QI to a new provider interface? Isn't the proc key enough? > 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. Should callers know that they are getting a shared copy? There are tons of places where permissions of certain files are assumed. What about file locking? Doug Turner [EMAIL PROTECTED]
