There has been some discussion in bug 93222 regarding backward compatibility of non frozen interfaces. Sounds like a bad thing to do, but Mozilla has to support some of these unfrozen and soon-to-be obsolete interface since plugins have shipped using these interfaces. Duh! If we don't support these interfaces, existing plugins will break. This is unacceptable for many.
The interfaces are nsIServiceManager, nsIComponentManager, nsIFile and nsIClassInfo. There are planned changes for these interfaces prior to the interface freeze. The question is, how do we support the obsolete interfaces? Two method surfaced, 1. we replace the current interface and rename it from nsI* to nsI*Obsolete. 2. we create a new interface named nsI*2. In either case, we would generate a new IID for the new interface. I think that the first solution is the most appealing when you think about a SDK. The first XPCOM SDK that we will ship will have many/most of the interfaces at version 2. Not really a big deal, but just aesthetically pleasing. I think that the second solution would be the normal case when bumping an interface version. In some cases, this would practically mean that we freeze both versions of the interface (nsIClassInfo), but in others, they would be completely different (nsIComponentManager). Does anyone have any preference or better ideas? doug turner [EMAIL PROTECTED]
