XPCOM plans
From MDC
Contents |
[edit] The Primary Goal: Shipping Mozilla.
Completed
The primary goal of XPCOM as stated over a year ago has been to ship a browser. We have reached this point and now we have multiple versions of the Mozilla browser, Netscape 6.x, Galleon, etc. Over the last few weeks, we have had conversations with various groups using XPCOM talking about what is next. One thing has been made crystal clear, customers do not want to spend energy keeping up with the changing API set. From these discussions, we believe that we should take a minimalist approach to the required XPCOM interfaces as we quickly approach the Mozilla 1.0 release (eg. only freeze the absolute minimum set of API required).
The two customers which critically need a stable API are plugins and embedding. Both are interested in a XPCOM API set that will allow XPCOM initialization, shutdown, and component/service management. We believe that for the Mozilla 1.0, XPCOM should at the minimum freeze an API that will give this functionality.
We have been working the embedding group and we have come up with this list of interfaces that we believe are required. (Note that some of these interfaces to not apply to XPCOM) If you see XPCOM interfaces that are missing from this list which you believe are required, please send mail to Doug Turner or post a message to the XPCOM newsgroup.
[edit] XPCOM's Road to Mozilla 1.0
The primary goal is to have a frozen interface to core xpcom functionality.
The current list of interfaces that are on the our list include basic "COM" functionality. Most of the functionality in XPCOM such as threading, reflection, many data structures, ect., will not be frozen in the pre-Mozilla 1.0 timeframe.
This SDK will include the frozen set of interfaces and a glue library. This set of interface has been defined by the embedding and plugin requirements. These interfaces include:
- nsIClassInfo
- nsIComponentManager
- nsIDirectoryService
- nsIDirectoryServiceProvider
- nsIFactory
- nsIFile
- nsIInputStream
- nsIInterfaceRequestor
- nsILocalFile
- nsIMemory
- nsIModule
- nsIObserver
- nsIOutputStream
- nsIProperties
- nsIServiceManager
- nsISimpleEnumerator
- nsISupports
- nsIWeakReference
The glue library will factor a set of the ease-of-use classes and macros, and non-frozen classes. This will allow components developers to utilize, for example, nsCOMPtr's without having to link to XPCOM. The secondary goal is to have a frozen interface to core xpcom functionality.
Once we have a set of interface that are frozen. We need to address startup/shutdown and threading problems within the implementation of these interface. Tracking bug 101976 lists the known problems that need to be addressed.
[edit] Post Mozilla 1.0: Improving XPCOM
The overall plan to improve XPCOM revolves around making it smaller, simpler, cleaner, more tuned to the facilities we need, and more aligned with applicable standards. The lighter we keep XPCOM, the easier it will be to debug, port, and maintain; and the less the cost to the embedding application. To that end, there should be no facilities in XPCOM that aren't highly leveraged. Things that exist only for a single client's use must be examined and hopefully exterminated.
A large fraction of XPCOMs facilities are aimed at C clients. We can expect embedding applications to exploit the Standard C Library. Where XPCOMs facilities overlap similar services provided by the Standard C Library we will want to transition our APIs and functionality to that of the standard. Eventually, clients can get the implementation from the Standard Library and our version can be removed.
For those facilities not provided by the Standard Library, we will still want to make their APIs as compatible as reasonable with it, e.g., our containers should work with the standard algorithms.
[edit] See Also
- Known Tasks
- bug 98278 - XPCOM API Changes metabug