80932 - Need a reusable, simple directory location provider object for embedders

Status: RESOLVED DUPLICATE of bug 76664

(Core Graveyard :: Embedding: APIs, defect)

Description

[Adam Lock]

The ActiveX control needs to implement a directory service provider object to 
keep its profiles and app data seperate Mozilla. It is clear that other 
embedders will need something similar. Rather than everyone "rolling their own", 
it makes sense to provide a simple implementation that will suit most embedders 
needs allowing them to set the root paths for application and profile data and 
pass that in to the call to NS_InitEmbedding. 

Since the object will be created before XPCOM is initialised, it should be 
created via a function called something such as NS_CreateFileLocationProvider 
which is part of the embedding API taking the application and profile paths as 
parameters.

Comment 1

[Adam Lock]

Attachment: Simple directory provider object, derived from the one in mfcEmbed

Comment 2

[Conrad Carlen (not reading bugmail)]

For the simple case, in which somebody doesn't wish to roll their own, we could
make it simpler. Instead of having NS_CreateFileLocationProvider take separate
aAppDataDir and aProfileRootDir params, I think it should just take one param:
aUserDataDir. This would be equivalent to aAppDataDir. The profile root dir is
simply a subdir called "Profiles" within the app data dir.

Also, if embeddors are to use this on any platform, the platform differences in
the hardcoded names of subdirs needs to be handled. See:
http://lxr.mozilla.org/seamonkey/source/xpcom/io/nsAppFileLocationProvider.cpp#78
for what SeaMonkey does.

The best way to handle the hard-coded names is to avoid them and use native
string resources. We can't use string bundles because the file location code
can't depend on the string bundle code. This is what I did in
CAppFileLocationProvider.cpp. The GetResCString routine could be filled in for
various platforms (except Unix where we might be stuck with hard-coded strings).

The advantage of string resources is that embeddors can rename things as well as
localize without changing the code.  

Comment 3

[Adam Lock]

How can we use string resources if XPCOM hasn't been initialised at this point? 

Comment 4

[Adam Lock]

Ack, submitted too soon. Here are some other questions

If we have one arg instead of two to initialise the provider wouldn't that be 
too restrictive for platforms where app-specific and user-specific data might be 
kept seperately? For example Unix might store app data in /var/cache and user 
data in $(HOME)/.something

Is it possible that the existing nsAppFileLocationProvider can be modified to 
make it configurable? The default behaviour would be as it is nowbut if someone 
created it via the NS_CreateFileLocProvider function it would be initialised 
to use the specified paths instead.

Comment 5

[Adam Lock]

Future

Comment 6

[Adam Lock]

Dupe against bug 76664. Try and produce a generic service provider object as
part of that bug

*** This bug has been marked as a duplicate of 76664 ***