Warning: The content of this article may be out of date. It was last edited in 2003 and is probably of historical interest only.
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.
nsStringTokenizerprobably 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.,
- 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.,
- 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_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
- 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
- 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,
nsCWeakReference, and (across threads) proxies (see nsISupports proxies).
- Author(s): unknown
- Last Updated Date: May 8, 2003
- Copyright Information: Portions of this content are © 1998–2007 by individual mozilla.org contributors; content available under a Creative Commons license | Details.