Closed
Bug 100368
Opened 23 years ago
Closed 23 years ago
Multiple Component Directory ability needed
Categories
(Core :: XPCOM, enhancement)
Core
XPCOM
Tracking
()
People
(Reporter: TaylorToddK, Assigned: dougt)
Details
An enhancement is needed to allow multiple directories to be scanned for xpcom
components. This feature is needed in cases that multiple browser instances
desire to share xpcom modules that already exist on the machine without having
to download and re-install for each instance of the browser.
Assignee | ||
Updated•23 years ago
|
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Assignee | ||
Comment 1•23 years ago
|
||
spoke to conrad about this a bit. We concluded that it would be best to just
have 3 defined directory properties:
NS_XPCOM_COMPONENT_DIR
NS_XPCOM_COMPONENT_USER_DIR
NS_XPCOM_COMPONENT_GLOBAL_DIR
Then have the embedding API call nsComponentManager::AutoRegister as it sees fit.
Comment 2•23 years ago
|
||
could we work the name 'SHARED' into those directory properties (somewhere) :-)
Comment 3•23 years ago
|
||
Are you planning to look for xpt files in these directories too? That would
require a fair chunk of work in the typelib loader. There were xpcom newsgroup
threads about that some time back. See my responses to Ari Heitner there on
threads with names like "Arbitrarily-located typelibs" and "Explicit loading of
typelibs".
Also, how is this this sharing going to manage component versioning issues?
Reporter | ||
Comment 4•23 years ago
|
||
The xpcom versioning is an issue that would have to be addressed. The primary
focus of having this enhancement is to support the vendor installation of xpcom
components via the windows registry mechanism. My questions for this would be:
1) Is the vendor's content page that provides the link to the component
checking for versioning at this level before providing a link to the installer?
2) Is there version checking done for any of the windows registry key methods,
the vendor checking versioning at install time? (If there are incompatible
Mozilla browser versions supporting the registry method, how does the vendor
know which browsers support the required version or does it simply drop its
module to all subscribers of the registry method? For example, if I download
the Real Player installation and it supports the windows registry method for
dropping plugin bits, will their process do any checking for mozilla xpcom
version 6 vs xpcom version 20? If not, isn't versioning already an issue?)
I had read the thread involving xpt and it is still unclear what the exact
problem is. Currently, plug-ins support an enumerated directory method for
multiple directories. I was informed component modules can be easily modified
to support this same method.
Can we come up with a list here of the the requirements and problems it would
take to complete this enhancement?
Comment 5•23 years ago
|
||
jband: I suspect xpt files will need to be supported too. Your versioning
question is a good one, dougt/dan?
At a minimum we need to ensure that all of our libs contain the appropriate
platform specific versioning data they're supposed to (I'm pretty sure windows
doesn't; do we have a bug for this?). But that doens't solve registry versioning
of components :-/.
This is a pretty big change in general I think. I also suspect it might
Assignee | ||
Comment 6•23 years ago
|
||
This bug is really a dup of a much older bug.
*** This bug has been marked as a duplicate of 14923 ***
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → DUPLICATE
You need to log in
before you can comment on or make changes to this bug.
Description
•