Judson Valeski wrote: > Doug Turner wrote: > >> The change, as I stated before, disables automatic component >> discovery and registration to be run in an optimized build. > > > isn't this functionality we've been counting on though? if by > "automatic component discovery" you mean determining when components > have been added, then registering them, then I think that breaks the > model; no? does it have MRE impact? what if an app drops a new > component into the component dir. Also, does this impact xpt > discovery/registration? > >> This should be a startup performance improvement for *all* embedders. > > > unless they just turn around and do the auto discovery by hand. > > Jud > Jud,
We agreed log ago that autoregistration at start up was a bad thing. The solution we agreed on was that new components would be installed into the system. The installer lets XPCOM know that there is new component. There is no "drop in" support like we have with plugins. You cant just take your favorite xpcom component and drop it into the components folder and expect it to work. I do not think that we should make the embedding code grovel over all of the xpcom components and xpti files every startup by default. If a embedder wants to do this, let them, but it shouldn't be the de facto thing we do. Does this have a MRE impact... no. None that I can see. Reading the header for this API, it does not say that XPCOM will run autoregistration. It only says that a component registry will be created if it doesn't exist. If you want to enable autoregistration by default in all builds, I can back out my change. However, I think that you are going to be asked why we stat every component at startup. -- Doug Turner [EMAIL PROTECTED]
