Okay, I have started on a new nsIServiceManager. The old stuff will still work, but it will be named nsIServiceManagerObsolete. The static class nsServiceManager will still be supported, but it will call through to the new stuff.
I will attach patches later this week. Doug Turner wrote: >> So you're saying that there _are_ existing, shipped plugins that will >> be broken by nsIClassInfo changes, in spite of the fact that we've >> already broken binary compatibility once? > > > > No, I am not saying that. I do not know of any plugins that use > nsIClassInfo. John or Patrick may know. But that is only one of the > interfaces that we need to address. There are others which are bound to > be used in existing plugins. > >> Which existing (shipped, working with existing Mozillas today) plugins >> break if we change which interfaces? Let's get all the cards on the >> table before we decide that we need to retrospectively freeze these >> interfaces. > > > > I know Java will be busted if we change either the nsIServiceManager or > the nsIComponentManager. Both have been slated for changes which will > break backwards. > >
