XPCOM Plans

The latest public version of this document is available at

• <http://www.mozilla.org/projects/xpcom/XPCOM_plans.html>

I'll keep this document up to date as we complete old plans, and come up with new ones. Please direct all comments and contributions to news:netscape.public.mozilla.xpcom and/or Scott Collins <scc@netscape.com>.

The Primary Goal: Shipping Mozilla and Communicator

We want XPCOM to be perfect; but our primary goal has to be shipping a browser.

Good Enough?

Wherever the cost, with respect to shipping a browser, of fixing or improving some XPCOM facility is greater than the cost of leaving it unchanged, the fix will have to wait. Hopefully, we'll be able to fix the things we think are most important, without negative impact on ongoing browser work. When we do, it will only be because the benefit of the fix excedes the cost.

The Secondary Goal: 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.

The Role of XPCOM

The XPCOM module roughly parallels the Standard C/C++ Libraries. It overlaps them significantly, but goes beyond them in capabilities. XPCOM sits above the Standard Libraries. It's role is to extend them with facilities tailored to [XP]COM development in general, and specifically the needs of Mozilla and Communicator. Like the Standard Libraries, XPCOM must be a fairly self-contained library, so as not to encumber clients with any unecessary external dependencies.

Changes to the Build Hierarchy

There are things in XPCOM that don't belong there. There is likely to be code outside of XPCOM that should be in it. There is code above XPCOM that should be below it.

• P3 I/O functionality (except for the filespec facility) probably doesn't belong in XPCOM; perhaps it should be moved to netwerk
• P3 The `Twips' units routines (or perhaps all routines) in "nsUnitConversion.h" probably belong in layout.
• P3 nsStringTokenizer probably belongs in the parser.
• 5.1 3rd party code that doesn't use any services from our tree should be below XPCOM; particularly, code XPCOM could exploit, e.g.,
  • expat
  • Berkeley db

Changes to APIs, Functionality, and Implementations

The following items are listed (very) roughly in their order of importance, i.e., fixing observers is the first thing I want to do.

• P1 The ownership model between nsObservers and the things they observe is broken. References between observers and observable objects should be weak. [See bug #18682]
• P1 The Service Manager and the Component Manager need to be unified.
• P1 Various threading issues, e.g.,
  • Too many locks. [See bug #13009]
  • Not enough locks. [See bugs #5795, #12914, and #12755]
• P1 Get rid of remaining AppCores, in favor of components, and or modules. [See bug #13021]
• P1 We would like to move to a scheme where no one writes QueryInterface, and we save code-space with a table driven implementation. A first step is moving all QI implementations to the table-like macros already in place (and some slight modifications to those macros).
• P1 We need to use NS_GET_IID instead of NS_DEFINE_IID. [See bug #12181]
• P1.5 nsIPtr is deprecated and needs to go away. [wasn't there a bug to go with this? Can't find it.]
• P2 Classes that parallel Standard Library classes should have compatible APIs, i.e.,
  • nsDeque [See bug #18505]
  • nsString
  • nsAVLTree
  • nsHashtable
  • our various array classes
  In some cases, this might initially be provided by additional interfaces. In all cases, we want to transition the primary APIs toward the standard.
• P2 Our various enumerator classes should be made compatible with the enumerators from the Standard C++ Library, so that we can apply the standard algorithms to our containers. This is probably best done with a C++ wrapper around an [XP]COM enumerator.
• P2 Do we still require our own version of QuickSort? And if so, can we narrow it to only those platforms that need it?
• P2 QueryInterface must not be used as a factory. [See bug #16543]
• P3 We need to check for aggregation in CreateInstance(). [See bug #16763]
• P3 Fix misspelled class names. [See bug #16951]
• P3 Convert remaining interfaces to IDL. [See bug #17705]
• 5.1 If the build hierarchy were fixed, the Registry could exploit expat and dbm. It could avoid implementing its own file format and io; and in many cases, possibly avoid calling into components for registration. In any case, the process of registration can, I think, be simplified.
• 5.1 Should we provide type-safe templatized containers, e.g., over nsISupportsArray?
• 5.1 We want to provide some mechanism for user-specific components in a multi-user environment.
• 5.1 Fix the shutdown issues that complicate life for embedding applications.

Things we need to Evangelize

We need to keep up-to-date documentation, samples, and have brown-bags to keep people informed. We've been doing this, but it should be in the plan.

• General [XP]COM guidelines. [See, e.g., XPCOM Code FAQ, IDL Author's Guide, and A Reference Implementation of QueryInterface]
• Writing and using components and modules.
• Building ownership models that work [see Some COM Ownership Guidelines], using raw pointers, nsCOMPtr [see The nsCOMPtr User's Manual], nsIWeakReference [see nsIWeakReference], nsCWeakReference, and (across threads) proxies [see nsISupports Proxies].