Closed Bug 100368 Opened 23 years ago Closed 23 years ago

Multiple Component Directory ability needed

Categories

(Core :: XPCOM, enhancement)

enhancement
Not set
normal

Tracking

()

RESOLVED DUPLICATE of bug 14923

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.
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
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.
could we work the name 'SHARED' into those directory properties (somewhere) :-)
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?
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?
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
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.