Judson Valeski wrote:
> 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.
>
> 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?
I work with a NFS mounted $HOME.
So when I go to another machine, my profile is there.
If I still have mozilla running my normal machine, I cannot
bring up mozilla on the new machine to check mail,
or chech a web page. Since I use mozilla to filter my mail,
I always leave it running at my desk machine.
Running other apps, based on mozilla, that share settings
would be nice too. galeon creates a seperate mozilla directory
and so does Nautilus. So I have 3 cache directoiries
and 3 sets of everything else. It would be nice to
share most of the configuration data between them.
>> 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)?
Why does mozilla hold prefs in memory like this?
It makes more sense to read them on startup, and write
them on changes. If the modification time changes to
be newer than the last time the process changed it, reread
the data. Prehaps ask firt, like NS4.x did with bookmarks.
Mozilla is one of the few apps I use that doesn't handle
multiple instances well., and is also one of the few that
one is likely to run multiple times.
-Thomas
