Opera 12.15 Source Code
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

index.html 8.6KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199
  1. <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
  2. "http://www.w3.org/TR/html4/loose.dtd">
  3. <html>
  4. <head>
  5. <link rel=stylesheet href="../coredoc.css" />
  6. <title>Opera Core from the outside</title>
  7. </head>
  8. <body>
  9. <h1>Opera Core from the outside</h1>
  10. <p>$Id$</p>
  11. <p>This document describes the common controlled API to the core code
  12. of Opera. Its intended audience is members of the Opera engineering
  13. department.</p>
  14. <h2>The Core API defines the Opera core</h2>
  15. <p>The Core API consists of a description of what the core does, plus
  16. code to access or activate that functionality. (See a separate
  17. section below for many more details.) Its purpose is to make most
  18. platform and customer requirements to the core visible in three ways:
  19. <ul>
  20. <li> as code that is visible in the API;
  21. <li> as core-internal features that can be turned on and off in a
  22. configuration file; or
  23. <li> as operational requirements on the core code.
  24. </ul>
  25. In particular, platform and customer requirements are no longer met by
  26. platform-group authored and owned code embedded inside the core code.
  27. Instead, to the greatest extent possible the requirements on the core
  28. are explicit, so that the core code does not meet them by accident,
  29. but by design; and all core code is controlled by the core group.</p>
  30. <h2>Block diagram</h2>
  31. <p>The following block diagram shows our working model of the view of
  32. the Core code from the outside. It is probably not complete, but it
  33. covers a large number of cases. Explanations to the various boxes
  34. follow below.</p>
  35. <pre>
  36. DreamWeaver, +-------------+ +---<b>GUI</b>---+
  37. Teleca UI, ... ---> |Customer code| | Plat. |
  38. +-------------+ | UI |
  39. Linux SDK, +--<b>Opera API</b>--+ | code |
  40. OperaBridge, -----> |Cust adaption| | |
  41. MacroMedia API, ... +-------------+ +---------+
  42. +---<b>Core utils</b>---+-----------<b>Core API upward</b>---------+----<b>Featurettes</b>---+
  43. | +-----------+ | +-------------------------------+ | +-----------+ |
  44. | | Util | | | Prefs WindowCommander | | | JsPlugins ==========> customer code
  45. | +-----------+ | +-------------------------------+ | +-----------+ |
  46. | | | +-----------+ |
  47. | | | | JVM ==========> (Sun) JVM
  48. | | | +-----------+ |
  49. | | | +-----------+ |
  50. | | Contents of core code | | NSPlugins ==========> 3rd party plugins
  51. | | may be controlled by | +-----------+ |
  52. | | settings of FEATURE_* | +-----------+ |
  53. | | | | ES Voice ==========> IBM code
  54. | | | +-----------+ |
  55. | | | +-----------+ |
  56. | | | | VoiceAPI ==========> IBM code
  57. | | | +-----------+ |
  58. | | | +-----------+ |
  59. | | +-------------------------------+ | | MailGlue ==========> M2
  60. | | | Prefs PortingInterfaces | | +-----------+ |
  61. | | +-------------------------------+ | ... |
  62. +----------------+---------<b>Core API downward</b>---------+------------------+
  63. +-----------------------------------+
  64. | Platform support code |
  65. +-----------------------------------+
  66. </pre>
  67. <dl>
  68. <dt><b>Core</b>
  69. <dd>The big box in the middle (with external APIs represented by "Core
  70. Utils", "Core API upward", "Core API downward", and "Featurettes")
  71. represents the core code.
  72. <dt><b>Major interfaces</b>
  73. <dd>Core exports an API upward to the user interface, this consists of
  74. WindowCommander and Preferences. It also exports an API downward to
  75. the platform support code, this consists of PortingInterfaces (which
  76. must be instantiated) and Preferences.
  77. <dt><b>Auxiliary interfaces ("Featurettes")</b>
  78. <dd>Core also exports special APIs directly to "customer" code, for
  79. example, JavaScript plugins and the Voice APIs. These featurettes are
  80. not related to porting Opera to a new platform but rather allow
  81. customer add-ins.
  82. <dt><b>Utility code</b>
  83. <dd> In addition, both kinds of platform code may rely on the Core
  84. Utilities functionality, a random collection of support code that does
  85. not have anything to do with browsing per se but may provide string,
  86. numeric, unicode, etc functionality.
  87. <dt><b>Features</b>
  88. <dd> The functionality in the Core, and sometimes aspects of the Core
  89. APIs, are controlled through a feature system that enable and disable
  90. various parts of the Core code.
  91. </dl>
  92. <p>It is probable that not all of Opera as it is now is representable
  93. in this architecture, so the drawing may change (or Opera may change).
  94. One example is Opera initialization: it does not obviously belong in
  95. WindowCommander or PortingInterfaces; and initialization order differs
  96. on different platforms, with platform code sometimes being initialized
  97. after some core pieces are ready but before others.</p>
  98. <h2>What is really the Core API?</h2>
  99. <p>It is the code we produce that we sell, but the core API is mostly
  100. <em>not</em> about code. Instead it is about structures that support
  101. the development of a reliable product, or in this case, a reliable
  102. core component.</p>
  103. <p>The Core API consists of at least these following parts. Note that
  104. one can make each of these arbitrarily complex; we aim to make them
  105. light-weight. (We have code to write.)</p>
  106. <h3>Interfaces: WindowCommander, Prefs, Util, and Featurettes.</h3>
  107. <ul>
  108. <li><em>Classes, methods, and constants.</em> Defined in header files.
  109. Documentation for these aspects is covered by the following section.
  110. <li><em>Supported Core FEATURES.</em> Defined in
  111. <a type="text/plain" href="../../../core/vfunc.h">core/vfunc.h</a>
  112. and documented in <a href="../../../core/vfunc.txt">core/vfunc.txt</a>.
  113. <li> <em><a href="envelope-of-change.html#soft">Assumptions the core
  114. code makes about the platform.</a></em> These are things that can be
  115. fixed if they turn out not to be true, but doing so may require
  116. substantial work.
  117. </ul>
  118. <h3>Documentation</h3>
  119. <ul>
  120. <li> <em><a href="../index.html">Metadocumentation and a map.</a></em> You're reading it.
  121. <li> <em>Interface documentation.</em> Mainly this is split into two parts:
  122. <ul>
  123. <li> Structural documentation is textual (HTML) and graphical (UML). Documentation
  124. is kept with the code and can/will be extracted onto the intranet automatically.
  125. <li> Each class, method, and constant is also documented doxygen-style in the code.
  126. This too can/will be extracted onto the intranet.
  127. </ul>
  128. <li> <em><a href="tutorials.html">Tutorials</a>, examples, FAQs.</em> Some of this may be placed on the Wiki.
  129. <li> <em><a href="design-principles.html">Design principles.</a></em>
  130. </ul>
  131. <h3>Non-interface aspects of the core code</h3>
  132. <ul>
  133. <li> <em><a href="envelope-of-change.html">Envelope of change.</a></em> These are the
  134. hard architectural constraints of the core code.
  135. <li> <em><a href="specifications.html">Specifications.</a></em> These are the things the
  136. core code should do or conform to that do not show up in interfaces, per se.
  137. <li> <em>Information.</em> This could be things like lists of the compilers we
  138. know we have used; 3rd party modules we use.
  139. </ul>
  140. <h3>Process</h3>
  141. <ul>
  142. <li> <em>Change requests.</em> How/when are requirements/needs communicated to the
  143. core; how do we implement them in a timely manner; etc.
  144. <li> <em>Principles for what we do.</em>
  145. <ul>
  146. <li>One principle is that requirements are to be communicated as functional
  147. requirements, not as code. Of course, code may be enclosed as a prototype
  148. implementation, but code does not constitute a requirement.
  149. </ul>
  150. <li> <em>How to track bugs.</em> The BTS is not a very good fit with our new
  151. module/product structure. This needs to be worked out.
  152. <li> <em>Release process.</em> Core will become a versioned product, with bug
  153. fixes and so on.
  154. <li> <em>Support.</em> Call +47 2416 4063, $10/minute. (Just joking.)
  155. </ul>
  156. <h3>Core code</h3>
  157. <ul>
  158. <li> The canonical core implementation
  159. <li> Selftest
  160. <li> Testsuites
  161. <li> Maybe dummy implementations of various interfaces to ease testing and porting
  162. </ul>
  163. </body>
  164. </html>