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