241155 - Support multiple 'components' directories

Status: RESOLVED FIXED

(Core :: XPCOM, enhancement)

Description

[Ben Goodger (use ben at mozilla dot org for email)]

As we discussed, the following new features for the Component Manager:

1. The ability to load a compreg.dat file from the profile directory.
2. The ability to locate an .autoreg file in the profile directory, followed
   by the following logic:
   
   - If the .autoreg file is empty, regenerate the compreg.dat file using the
     default component locations (GRE and application components)
   - If the .autoreg file is not empty, regenerate the compreg.dat file using
     the default component locations (GRE and application components) and also
     register all components in the locations specified in the lines in the
     .autoreg file, which look like this:

     reg:extensions/{GUID1}/components/
     reg:extensions/{GUID2}/components/
     reg:extensions/{GUID3}/components/
     [...]

     ... where "reg:" is a key that means "relative to the location of the
     compreg.dat file"

Comment 1

[Darin Fisher]

*** Bug 241885 has been marked as a duplicate of this bug. ***

Comment 2

[Darin Fisher]

In bug 240553, bsmedberg wrote:

> Why do we need to keep a list of directories? The extension manager can/should
> call nsIComponentRegistrar->AutoRegister(somedir) when it first installs an
> extension. At that point, we're done and we don't need to keep a list, do we?
> 
> We *do* need to fix the .autoreg situation. I was planning on adding a .lastreg
> file which we can compare timestamps on. This file should be checked in
> [bindir]/.lastreg and [profiledir]/[buildid]/.lastreg
> 
> Unlike the current .autoreg file, XPCOM shouldn't delete the .lastreg file,
> because other profiles will not have a chance to do autoreg.

Comment 3

[Darin Fisher]

> Why do we need to keep a list of directories? The extension manager can/should
> call nsIComponentRegistrar->AutoRegister(somedir) when it first installs an
> extension. At that point, we're done and we don't need to keep a list, do we?

Good questions.  I'm not sure that your suggestion isn't valid.  It might be a
lot better in fact...

Using your suggestion, we could have the extension manager AutoRegister newly
installed extensions at startup.  That would take care of extension
installation.  For extension uninstall, we need to force XPCOM to re-register
everything since an extension might have overridden some built-in component. 
So, if the user asks us to uninstall an extension, then on the next start of the
application, we can manually call AutoRegister(nsnull) followed by
AutoRegister(dir) for each extension dir that is still installed.

That does sound better.

Your .lastreg suggestion wouldn't be something xpcom looks at... it would be
something the application startup logic would look at right?

Comment 4

[Darin Fisher]

> Your .lastreg suggestion wouldn't be something xpcom looks at... it would be
> something the application startup logic would look at right?

Change this sentence to: .lastreg could be a managed entirely by the app startup
logic, right?  that way, xpcom doesn't need to know anything about there being
two .lastreg files.  currently, xpcom doesn't know much about profiles, and we
should probably try to keep it that way.

Comment 5

[Benjamin Smedberg]

(In reply to comment #4)
> Change this sentence to: .lastreg could be a managed entirely by the app startup
> logic, right?  that way, xpcom doesn't need to know anything about there being

Well... currently XPCOM handles the .autoreg logic at
http://lxr.mozilla.org/mozilla/source/xpcom/build/nsXPComInit.cpp#231

The problem with handling this entirely in appstartup is that you want to call
the autoreg after you've got XPCOM, but before you fire the xpcom-startup observers.

Comment 6

[Darin Fisher]

maybe we need a pre- "xpcom-startup" event?

Comment 7

[Darin Fisher]

Bsmedberg and I discussed this bug over IRC, and came up with the following
alternate plan:

 (1) invent a directory service key that corresponds to an enumeration of 
     'components' directories (let the key be called "ComsDL" for the purposes
     of this discussion).

 (2) extension manager (EM) should populate a list of 'components' directories 
     in a location that is known by the app startup code.

 (3) the app startup code reads in the list of 'components' directories at 
     startup and uses it to provide ComsDL.

 (4) NS_InitXPCOM2 iterates over ComsDL, calling AutoRegister on each of the
     directories.

 (5) xptiInterfaceInfoManager's search path will include the elements of ComsDL
     as well, which enables support for XPT files in the extra components
     directories.

In (4) and (5), we are basically extending what is already done to support a
components directory both in the application directory as well as the GRE directory.

If EM wants to force autoreg (because an extensions has been added/enabled or
removed/disabled), it can use existing mechanisms to do that.

Comment 8

[Darin Fisher]

Unfortunately, we cannot use bsmedberg's suggestion of calling AutoRegister
manually since there is no way to register XPT files in the components
directories.  xptiInterfaceInfoManager has a search path that must be configured
before the xptiInterfaceInfoManager is initialized.  So, instead of trying to
rework xptiInterfaceInfoManager, I think we agreed that it is better to go for
something simpler, which is the plan I outlined above.

Comment 9

[Darin Fisher]

Attachment: v0 patch

Here's an untested patch that implements the XPCOM part of the changes outlined
above.

Comment 10

[Darin Fisher]

Comment on attachment 147166 [details] [diff] [review]
v0 patch

I haven't decided yet if autoreg of the dirList should be considered a fatal
error.	Anyone have thoughts on that?

Also, I'm not sure if it is important to worry about extensions that define new
component loaders.  Maybe it would matter if for example we wanted to allow the
python-connect code to be installed as an extension to the browser.  The
problem is tricky, since I think I would need to re-autoreg the entire dirList
if a component loader is added.

Comment 11

[Darin Fisher]

Comment on attachment 147166 [details] [diff] [review]
v0 patch

bsmedberg: this patch isn't final, but i'd like to get your feedback on this. 
thx!

Comment 12

[timeless]

Comment on attachment 147166 [details] [diff] [review]
v0 patch

>+/* Property will return a list of components directories that will
is "component directories" ok?
>+ * will be registered after the application components directory.
.
>+ */
>+#define NS_XPCOM_COMPONENT_DIR_LIST             "ComsDL"

Comment 13

[Darin Fisher]

maybe i should quote "components" ;-)

Comment 14

[Benjamin Smedberg]

Comment on attachment 147166 [details] [diff] [review]
v0 patch

Don't worry about new componentloaders yet.

There was old code in nsxpcominit which *did* worry about it when we were
registering the GRE after local components, but I switched the order and
removed it. We can resurrect that if it becomes an issue (i.e. if shaver needs
it)

Comment 15

[Darin Fisher]

dougt gave his moa= for this patch over AIM.

Comment 16

[Darin Fisher]

fixed-on-trunk

Comment 17

[Darin Fisher]

This patch has been checked in on AVIARY_1_0_20040515_BRANCH for use by the new
firefox Extension Manager.