212212 - Allow non-persistent registration of modules

Status: RESOLVED INVALID

(Core :: XPCOM, enhancement)

Description

[Benjamin Smedberg]

For the extension manager I'm working on, I want per-profile extensions.
However, installing these extensions should not affect the application
xpti/compreg data. I can imagine several ways to implement this, but the
simplest is to have an extended nsIModule/nsIComponentRegistrar interface:

interface nsIModuleEx : nsIModule
{
  registerSelfNonPersist(...);
  unregisterSelfNonPersist(...);
};

interface nsIComponentRegistrarEx : nsIComponentRegistrar
{
  autoRegisterNonPersist(...);
  autoUnregisterNonPersist(...);
};

Combining these four methods, the existing nsIModule.registerFactory method and
the aPersist flag on the category manager allow modules to "register" themself
for the current session, without affecting persistent data.

There is no need for modules to implement nsIModuleEx unless they are extensions
and expect to be enabled/disabled per-profile.

dougt, let me know if these IDL signatures look good... the change to the
component registrar is insanely simple, and I would like to add new generic
module macros.

Comment 1

[Doug Turner (:dougt)]

For non-persistent registration, the application should just call autoregister
at startup, and autounregister at shutdown.

I am against per-profile components since by the time the mozilla application
knows about the "profile", it is to late to register most components/xpt files.

Comment 2

[Benjamin Smedberg]

Are the xpti/compreg only written at shutdown? I'm worried that component
registration information will "leak" in the event of a crash.

Comment 3

[Doug Turner (:dougt)]

the it will be "freed" the next time the app shutdown.

Comment 4

[Benjamin Smedberg]

dougt: you can mark this bug INVALID then, but I'm not sure I understand
completely...

0) xpti/compreg is read at startup. There is no "extension information" stored
in xpti/compreg

1) During startup (after a profile is selected, maybe) my "extension manager"
calls autoRegister() on an extension
1a) is xpti/compreg updated at this time?

2) The program crashes
2a) at this point isn't "bad" information stored in xpti/compreg?

3) The program starts up again, using another profile
3a) isn't it using the "bad" information (and won't "free" it at shutdown)?

Comment 5

[Axel Hecht]

More puzzled folks on CC.

<dbradley> bsmedberg: We already handle dynamic generation of interfaces ie SOAP

Comment 6

[Benjamin Smedberg]

dougt: this problem is even more serious than I thought... xpti/compreg.dat are
written during execution, not merely at shutdown. So the potential "registration
leaks" are far greater. Do have a serious objection to the nsIModuleEx proposal?
It would not affect normal mozilla operation at all (only extension components
would need to implement nsIModuleEx).

Comment 7

[Doug Turner (:dougt)]

i do not want an interface that extends module info.  I wouldn't (ask much) mind
a interface that controls when / how to rewrite out the persistent store.

Comment 8

[Benjamin Smedberg]

dougt: how about only writing the persistent store at shutdown?

Comment 9

[Doug Turner (:dougt)]

we would have to postpone all flushes till the application shutdown.  things
that can trigger a flush would include adding a new plugin, etc.  If you crash
before shutdown after an plugin install, you will not be able to use it next
time you start up.

Comment 10

[Benjamin Smedberg]

I'm sorry if I'm a little frustrated with this bug... I still like my
nsIModuleEx proposal best: firstly because it is elegant and makes good use of
XPCOM extensibility, secondly because there is no chance of leaking registration
information, and thirdly because it wouldn't need any pervasive changes in the
current mozilla codebase, and it's unlikely to cause any regressions in any
existing code.

Because you're the module owner and don't like my plan, I'm willing to try other
solutions, like controlling the xpti/compreg disk flush, but they are almost
certain to cause bizarre regressions, as you point out with the plugin example.

Comment 11

[Benjamin Smedberg]

Attachment: nsIModuleLoader, replacement for nsIComponentLoader

I now realize why extensions to nsIModule would be so difficult... they would
require modifications to all of the component loaders. So I was looking at the
component loaders, and they all share significant portions of code. I think
that we could reduce the amount of code duplication and make nsIModule more
extensible all at the same time. Instead of *component* loaders (which need to
know the internals of nsIModule), use *module* loaders. The component manager
does the gruntwork, instead of each component loader. dougt, see the attached
interface proposal.

Comment 12

[Benjamin Smedberg]

hyatt and I talked, and he wants XPTI/COMPREG stored in the "profile" for the
new-style apps (FB/TB), so this doesn't affect the extension system any more. I
see that nsIComponentManagerObsolete had non-persistent registration which was
removed during the switch to nsIComponentManager.

Doug, I think non-persistent reg is a good thing, but if you really don't want
this, can you WONTFIX it?

Comment 13

[Christian :Biesinger (don't email me, ping me on IRC)]

>see that nsIComponentManagerObsolete had non-persistent registration which was
>removed during the switch to nsIComponentManager.

eh?
use this:
http://lxr.mozilla.org/seamonkey/source/xpcom/components/nsIComponentRegistrar.idl#93

Comment 14

[Doug Turner (:dougt)]

see #1.