The Role of XPCOM

The XPCOM module roughly parallels the C/C++ standard libraries. It overlaps them significantly, but goes beyond them in capabilities. XPCOM sits above the standard libraries. Its role is to extend them with facilities tailored to XPCOM development in general, and specifically the needs of Mozilla. Like the standard libraries, XPCOM must be a fairly self-contained library, so as not to encumber clients with any unnecessary 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 Various threading issues, e.g.,
  • Too many locks. See bug 13009.
  • Not enough locks. See bug 5795, bug 12755, and bug 12755.
• 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). See bug 23737 Work is progressing on this. See in particular, the new NS_INTERFACE_MAP_... macros in "nsISupportsUtils.h".
• P1 We need to use NS_GET_IID instead of NS_DEFINE_IID. See bug 25886. Work is progressing on this.
• P2 Classes that parallel Standard Library classes should have compatible APIs, i.e.,
  • nsDeque 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 XPCOM 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?
• P3 We need to check for aggregation in CreateInstance(). See bug 16763
• P3 Improve the performance of the registry. Explore the idea of using a separate registry.
• 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 XPCOM guidelines. See, e.g., XPCOM Code FAQ, IDL Author's Guide, and Implementing QueryInterface.
• Writing and using components and modules.
• Building ownership models that work (see XPCOM ownership guidelines), using raw pointers, nsCOMPtr (see The nsCOMPtr User's Manual), nsIWeakReference (see nsIWeakReference), nsCWeakReference, and (across threads) proxies (see nsISupports proxies).