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.
P3nsStringTokenizer 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.
Completed items are rendered as strikethrough text.
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.
[See bug #23736]
P1
Get rid of remaining AppCores, in favor of components, and or modules.
[See bug #13021]
This bug remains open as there are remnants of AppCores in the build system,
though, according to the bug, not in the executable.
P1
Change ProgIDs to CompanyName.ProductName.Version from <component://...>.
[See bug #26013]
P1
Reimplement the category manager in C++.
It is currently written in JavaScript which makes JavaScript a dependency for XPCOM.
[See bug #26011]
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 bugs
#12181, and
#25886]
Work is progressing on this.
P1.5nsIPtr is deprecated and needs to go away.
[See bug #23738]
P2
Classes that parallel Standard Library classes should have compatible APIs, i.e.,
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?
P2QueryInterface must not be used as a factory.
[See bug #16543]
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.
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.
