| 1 | <html>
|
|---|
| 2 | <!-- ***** BEGIN LICENSE BLOCK *****
|
|---|
| 3 | - Version: MPL 1.1/GPL 2.0/LGPL 2.1
|
|---|
| 4 | -
|
|---|
| 5 | - The contents of this file are subject to the Mozilla Public License Version
|
|---|
| 6 | - 1.1 (the "License"); you may not use this file except in compliance with
|
|---|
| 7 | - the License. You may obtain a copy of the License at
|
|---|
| 8 | - http://www.mozilla.org/MPL/
|
|---|
| 9 | -
|
|---|
| 10 | - Software distributed under the License is distributed on an "AS IS" basis,
|
|---|
| 11 | - WITHOUT WARRANTY OF ANY KIND, either express or implied. See the License
|
|---|
| 12 | - for the specific language governing rights and limitations under the
|
|---|
| 13 | - License.
|
|---|
| 14 | -
|
|---|
| 15 | - The Original Code is PyXPCOM.
|
|---|
| 16 | -
|
|---|
| 17 | - The Initial Developer of the Original Code is
|
|---|
| 18 | - ActiveState Tool Corporation.
|
|---|
| 19 | - Portions created by the Initial Developer are Copyright (C) 2000-2001
|
|---|
| 20 | - the Initial Developer. All Rights Reserved.
|
|---|
| 21 | -
|
|---|
| 22 | - Contributor(s):
|
|---|
| 23 | -
|
|---|
| 24 | - Alternatively, the contents of this file may be used under the terms of
|
|---|
| 25 | - either the GNU General Public License Version 2 or later (the "GPL"), or
|
|---|
| 26 | - the GNU Lesser General Public License Version 2.1 or later (the "LGPL"),
|
|---|
| 27 | - in which case the provisions of the GPL or the LGPL are applicable instead
|
|---|
| 28 | - of those above. If you wish to allow use of your version of this file only
|
|---|
| 29 | - under the terms of either the GPL or the LGPL, and not to allow others to
|
|---|
| 30 | - use your version of this file under the terms of the MPL, indicate your
|
|---|
| 31 | - decision by deleting the provisions above and replace them with the notice
|
|---|
| 32 | - and other provisions required by the LGPL or the GPL. If you do not delete
|
|---|
| 33 | - the provisions above, a recipient may use your version of this file under
|
|---|
| 34 | - the terms of any one of the MPL, the GPL or the LGPL.
|
|---|
| 35 | -
|
|---|
| 36 | - ***** END LICENSE BLOCK ***** -->
|
|---|
| 37 |
|
|---|
| 38 | <head>
|
|---|
| 39 | <meta http-equiv="Content-Type" content="text/html; charset=windows-1252">
|
|---|
| 40 | <meta name="GENERATOR" content="Microsoft FrontPage 4.0">
|
|---|
| 41 | <meta name="ProgId" content="FrontPage.Editor.Document">
|
|---|
| 42 | <title>Architecture</title>
|
|---|
| 43 | </head>
|
|---|
| 44 |
|
|---|
| 45 | <body>
|
|---|
| 46 |
|
|---|
| 47 | <h1>Python XPCOM Package Architecture</h1>
|
|---|
| 48 | <h2><a name="Architecture">Architecture</a></h2>
|
|---|
| 49 | <p>Much of the design for the Python XPCOM Package has been borrowed from the Python MS-COM
|
|---|
| 50 | extensions in <i>win32com</i>. Most of the major limitations and drawbacks in the <i>win32com</i>
|
|---|
| 51 | design have been addressed, mainly "auto-wrapping" of
|
|---|
| 52 | interface objects, which is not supported by <i>win32com</i>.</p>
|
|---|
| 53 | <p>Like <i>win32com</i>, this architecture includes the concept of <i>client COM</i> and <i>server
|
|---|
| 54 | COM.</i> </p>
|
|---|
| 55 | <p>Client COM:</p>
|
|---|
| 56 | <ul>
|
|---|
| 57 | <li>calls other interfaces</li>
|
|---|
| 58 | <li>is supported by <i>PyInterfaces</i> implemented in C++, which assists
|
|---|
| 59 | in making the COM calls</li>
|
|---|
| 60 | <li>is supported by <i>PyGateways</i>, which assists in receiving
|
|---|
| 61 | external COM calls and dispatching them to the correct Python object</li>
|
|---|
| 62 | <li> is supported in the <i>xpcom/client</i> package</li>
|
|---|
| 63 | </ul>
|
|---|
| 64 | <p>Server COM:</p>
|
|---|
| 65 | <ul>
|
|---|
| 66 | <li>implements interfaces for use by other XPCOM applications or components</li>
|
|---|
| 67 | <li> is
|
|---|
| 68 | supported in the <i>xpcom/server</i> package</li>
|
|---|
| 69 | </ul>
|
|---|
| 70 | <p>The XPConnect framework is very powerful, and far exceeds what COM's <i>
|
|---|
| 71 | IDispatch</i> can offer. Thus, we are able to get by with far fewer interfaces
|
|---|
| 72 | supported in the C++ level, and defer most things to the Python code that uses
|
|---|
| 73 | XPConnect. As a result, the requirement for a huge number of interfaces to
|
|---|
| 74 | exist in the <i>.pyd</i> does not exist. There are, however, a number of
|
|---|
| 75 | interfaces that do require native C++ support: these are interfaces
|
|---|
| 76 | required to "boot" the XPConnect support (i.e., the interfaces that are
|
|---|
| 77 | used to get information about interfaces), and also two gateways that need to
|
|---|
| 78 | work without interface information available. This last requirement is
|
|---|
| 79 | due to the XPCOM shutdown-ordering - it may be a bug, but is not an unreasonable
|
|---|
| 80 | amount of code anyway.</p>
|
|---|
| 81 | <p><b>Auto-wrapping</b> of COM objects is supported by both client COM and
|
|---|
| 82 | server COM. For client COM, auto-wrapping means that the
|
|---|
| 83 | Python programmer always sees Python "component" objects, rather than
|
|---|
| 84 | raw C++ interface objects; to the user, it all appears to "just
|
|---|
| 85 | work". This is a major source of frustration in the <i>win32com</i>
|
|---|
| 86 | framework.</p>
|
|---|
| 87 | <p>For server COM, auto-wrapping means that you can
|
|---|
| 88 | pass Python instances wherever a COM object is expected. If the Python
|
|---|
| 89 | instance supports COM interfaces, by virtue of having a <i>_com_interfaces_</i>
|
|---|
| 90 | attribute that lists the interface requested, it will be automatically wrapped
|
|---|
| 91 | in the correct COM object. </p>
|
|---|
| 92 | <p><b>Error Handling:</b> The C++ framework has good error handling support,
|
|---|
| 93 | and uses the XPCOM console service to log debug messages, Python exceptions and
|
|---|
| 94 | tracebacks. <i>win32com</i> does not have good exception/traceback support
|
|---|
| 95 | at the C++ level, mainly because COM does not define a service like
|
|---|
| 96 | the console where debug messages can go. This does mean that in Mozilla
|
|---|
| 97 | release builds, these debug messages are likely to be lost, but the <i>--console</i>
|
|---|
| 98 | command line option to a release Mozilla will get them back. Therefore,
|
|---|
| 99 | the other error-support utilities, such as the error callbacks made on the
|
|---|
| 100 | policy object, may be used.</p>
|
|---|
| 101 | <p><b>Component Loader, Modules and Factories:</b> XPCOM has the concept
|
|---|
| 102 | of a component loader - a module used to load all components of a
|
|---|
| 103 | particular type. For example, the <i>moz.jsloader.1</i> component loads all
|
|---|
| 104 | the JavaScript components. Similarly, the <i>moz.pyloader.1</i>
|
|---|
| 105 | component loads all Python components. However, unlike
|
|---|
| 106 | JavaScript, the Python component loader is actually implemented in Python
|
|---|
| 107 | itself! Since the Python component loader can not be used to load
|
|---|
| 108 | itself, this component has some special code, <i>pyloader.dll,</i> to boot-strap itself.</p>
|
|---|
| 109 | <p>This means is that all XPCOM components, including the Python loader itself and all
|
|---|
| 110 | XPCOM module and factory interfaces, are implemented in
|
|---|
| 111 | Python. <b>There are no components or interfaces implemented purely in C++
|
|---|
| 112 | in this entire package!</b></p>
|
|---|
| 113 |
|
|---|
| 114 | </body>
|
|---|
| 115 |
|
|---|
| 116 | </html>
|
|---|
