Re: Freezing Embedding Interfaces...

[Rick Potts]

hey doug,

i don't think that we are ready (or should be willing) to freeze our Event Q story.  I think that we should try to shield external consumers from nsIEventQueue and nsIEventQueueService at all cost.

Please, lets not freeze them unless there is no other option!

-- rick

Doug Turner wrote:

I am pushing to freeze the core parts of XPCOM.  The reason is simple, changes are busting users of xpcom clients.  There needs to be a definitive list of the frozen API which embedders and xpcom developers can reference.

Here is the first cut of the XPCOM interfaces that need to be frozen.  This list was generated by looking at various uses of XPCOM.  It is a minimal list.  I explicitly ignored many of the data structures, io streams, typeinfo, ect.

If you are using xpcom in your project, please take a look at the interfaces you are using.  Please send me that list.  This will help me guide which interface need to be frozen sooner.

Structs:
nsID
nsIID

Header Files and Utils
nsCOMPtr and friends
Strings
nsISupportUtils
nsAgg.h
nsDebug.h
nsIGenericFactory.h

Core XPCOM Interfaces:
nsISupport
nsIInterfaceRequestor
nsIWeakReference
nsIFactory
nsIComponentManager
nsIServiceManager
nsIShutdownListener (can we get rid of??)
nsIMemory

Threading
nsIEventQueue
nsIEventQueueService

File Location
sniffle

nsILocalFile
nsIProperties
nsIDirectoryService
nsIDirectoryServiceProvider
nsIFileSpec (deprecated but some legacy code uses it)

DS
nsIEnumerator
nsIObserver

IOU
nsIOutputStream
nsIInputStream

There are a few bugs those that are interested can add themselves to:

XPCOM API http://bugzilla.mozilla.org/show_bug.cgi?id=98278
Mother of API changes http://bugzilla.mozilla.org/show_bug.cgi?id=70229

If you are responding about a particular interface, please create a new thread.

Looking forward to hear your feedback,

Doug