We need to we enable the local installation of XPCOM components (including new plug-ins) by users on Linux who are running a Mozilla-based browser from a shared server directory to which they do not have write access Navigator 4 enabled this for plug-ins via a local plugins directory in the user's profile. Users running Nav4 from a shared server directory could install plug-ins locally in their profile's plugins directory, and plug-ins installed in the profile's directory took precedence over any conflicting plug-ins in the shared server directory. There should be a local components directory in the user's profile (see bug 45701), and the XPCOM initialization code should check this for XPCOM components (including XPCOM components that happen to be new plug-ins) and load them, with these local XPCOM components taking precedence over any shared ones installed on the server (i.e. the user's profile's components directory should be checked last).

This is related to the general effort, by me, to create a component search path, I think, which I wrote a description on, but I haven't posten on recently. Is it required to only allow plugins in the local directory, or is this local directory a place where any components may be placed?

Given the view that plugins (using the new APIs) are Components. It would seem more orthogonal (and I suspect easier on the code ?) if a local per user directory was searched for all components.

Marking FUTURE as Netscape engineering is overburdened. This amounts to an enhancement request for enabling distributed installation of components in shared installation environments, and the target for FCS is individual consumers. For the first release, we can settle for users having to install components centrally. helpwanted--mozilla community members by all means please sign up to lend a hand!

I currently intend to add support for component search path in nsbeta3, which solves a number of problems including this one.

Well, it will not be nsbeta3.

Edward: Welcome to xpcom!

Once again... attempting to reassign from Ray to Edward.

reassign all kandrot xpcom bug.

This is essentially a duplicate of 14923, but I'll mark it a blocker of that tracking bug so as not to knock off all the people cc'd on this bug.

dan, noble, but I need to clear my bug list. marking as dup. *** This bug has been marked as a duplicate of 14923 ***