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"

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

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.

> 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?

> 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.

(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.

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

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.

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.

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

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 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 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"

maybe i should quote "components" ;-)

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)

dougt gave his moa= for this patch over AIM.

fixed-on-trunk

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