XPCOM tasks

  • Revision slug: XPCOM_tasks
  • Revision title: XPCOM tasks
  • Revision id: 182618
  • Created:
  • Creator: Jorend
  • Is current revision? No
  • Comment /* Changes to APIs, Functionality, and Implementations */

Revision Content

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 {{template.Bug(13009)}}.
    • Not enough locks. See {{template.Bug(5795)}}, {{template.Bug(12914)}}, and {{template.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 {{template.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 {{template.Bug(25886)}}. Work is progressing on this.
  • P2 Classes that parallel Standard Library classes should have compatible APIs, i.e.,
    • nsDeque {{template.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 {{template.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.

Revision Source

<h4 name="The_Role_of_XPCOM"> The Role of XPCOM </h4>
<p>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.
</p>
<h4 name="Changes_to_the_Build_Hierarchy"> Changes to the Build Hierarchy </h4>
<p>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.
</p>
<ul><li> <span class="editor-note">P3</span> I/O functionality (except for the filespec facility) probably <i>doesn't</i> belong in XPCOM; perhaps it should be moved to netwerk
</li><li> <span class="editor-note">P3</span> The `Twips' units routines (or perhaps all routines) in "nsUnitConversion.h" probably belong in layout.
</li><li> <span class="editor-note">P3</span> <code>nsStringTokenizer</code> probably belongs in the parser.
</li><li> <span class="editor-note">5.1</span> 3rd party code that doesn't use any services from our tree should be below XPCOM; particularly, code XPCOM could exploit, e.g.,
<ul><li> expat
</li><li> Berkeley db
</li></ul>
</li></ul>
<h4 name="Changes_to_APIs.2C_Functionality.2C_and_Implementations"> Changes to APIs, Functionality, and Implementations </h4>
<p>The following items are listed (very) roughly in their order of importance, i.e., fixing observers is the first thing I want to do.
</p>
<ul><li> <span class="editor-note">P1</span> Various threading issues, e.g.,
<ul><li> Too many locks. See {{template.Bug(13009)}}.
</li><li> Not enough locks. See {{template.Bug(5795)}}, {{template.Bug(12914)}}, and {{template.Bug(12755)}}.
</li></ul>
</li><li> <span class="editor-note">P1</span> We would like to move to a scheme where no one writes <code>QueryInterface</code>, 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 {{template.Bug(23737)}} <span class="editor-note"> Work is progressing on this. See in particular, the new <code>NS_INTERFACE_MAP_...</code> macros in <a class="external" href="http://lxr.mozilla.org/seamonkey/source/xpcom/base/nsISupportsUtils.h">"nsISupportsUtils.h"</a>. </span>
</li><li> <span class="editor-note">P1</span> We need to use <code>NS_GET_IID</code> instead of <code>NS_DEFINE_IID</code>. See {{template.Bug(25886)}}.  <span class="editor-note"> Work is progressing on this. </span>
</li><li> <span class="editor-note">P2</span> Classes that parallel Standard Library classes should have compatible APIs, i.e.,
<ul><li> nsDeque {{template.Bug(18505)}}
</li><li> nsString
</li><li> nsAVLTree
</li><li> nsHashtable
</li><li> 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.
</li></ul>
</li><li> <span class="editor-note">P2</span> 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.
</li><li> <span class="editor-note">P2</span> Do we still require our own version of QuickSort? And if so, can we narrow it to only those platforms that need it?
</li><li> <span class="editor-note">P3</span> We need to check for aggregation in <code>CreateInstance()</code>. See {{template.Bug(16763)}}
</li><li> <span class="editor-note">P3</span> Improve the performance of the registry. Explore the idea of using a separate registry.
</li><li> <span class="editor-note">5.1</span> 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.
</li><li> <span class="editor-note">5.1</span> Should we provide type-safe templatized containers, e.g., over <code>nsISupportsArray</code>?
</li><li> <span class="editor-note">5.1</span> We want to provide some mechanism for user-specific components in a multi-user environment.
</li><li> <span class="editor-note">5.1</span> Fix the shutdown issues that complicate life for embedding applications.
</li></ul>
<h4 name="Things_we_need_to_Evangelize"> Things we need to Evangelize </h4>
<p>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.
</p>
<ul><li> General XPCOM guidelines. See, e.g., <a class="external" href="http://lxr.mozilla.org/mozilla/source/xpcom/doc/xpcom-code-faq.html">XPCOM Code FAQ</a>, <a class="external" href="http://www.mozilla.org/scriptable/xpidl/idl-authors-guide/index.html">IDL Author's Guide</a>, and <a href="en/Implementing_QueryInterface">Implementing QueryInterface</a>.
</li><li> Writing and using components and modules.
</li><li> Building ownership models that work (see <a href="en/XPCOM_ownership_guidelines">XPCOM ownership guidelines</a>), using raw pointers, <code>nsCOMPtr</code> (see <a class="external" href="http://www.mozilla.org/projects/xpcom/nsCOMPtr.html">The <code>nsCOMPtr</code> User's Manual</a>), <code>nsIWeakReference</code> (see <a class="external" href="http://www.mozilla.org/projects/xpcom/weak_references.html"><code>nsIWeakReference</code></a>), <code>nsCWeakReference</code>, and (across threads) proxies (see <a href="en/NsISupports_Proxies">nsISupports Proxies</a>).
</li></ul>
Revert to this revision