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.

envelope-of-change.html 5.9KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167
  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: Envelope of change</title>
  7. </head>
  8. <body>
  9. <h1>Opera Core: Envelope of change</h1>
  10. $Id$
  11. <a name="hard">
  12. <h2>Fundamental constraints in the Core</h2>
  13. <p>One sometimes talks about the "envelope of change" of a system to
  14. refer to the the fundamental constraints of the system: those
  15. assumptions that it could be very costly to change generally. What is
  16. outside the envelope is hard to attain; what is inside is already
  17. accounted for in the architecture and can be implemented in a
  18. straightforward way.</p>
  19. <p>A typical example of something that was outside the envelope of
  20. change is the out-of-memory handling introduced in Opera&nbsp;6--it
  21. affected virtually every line of core code and was quite costly to
  22. implement. The result is a product that is deeply different than the
  23. one we started with.</p>
  24. <p>The following list is not complete.</p>
  25. <dl>
  26. <dt><b>Single-threaded execution of core code</b>
  27. <dd>The core code assumes that it always executes in a critical
  28. section; supporting multithreaded execution would be a large
  29. undertaking.
  30. <dt><b>Floating-point support is required</b>
  31. <dd>Some modules must be substantially reengineered if floating-point
  32. support is not available at all. (One example is the ECMAScript
  33. engine; no doubt there are other modules, which we will document here.)
  34. <dt><b>C++ is required</b>
  35. <dd>It sounds silly even to mention it, but we do require C++ to be
  36. supported. Not every <a
  37. href="http://www.cs.bell-labs.com/plan9">interesting platform</a> has
  38. C++.
  39. <dt><b>Not designed for plug-and-play external components</b>
  40. <dd>A number of components in Opera are deeply embedded in the overall
  41. working of the browser and cannot easily be replaced by external
  42. components, at least not while leaving the feel of the system intact.
  43. Among other things, this could be because typical external components
  44. do not fit in our interleaved reading-parsing-layout mechanism.
  45. </dl>
  46. <h2>Non-constraints in the Core</h2>
  47. <p>Some things are explicitly not required and are documented here so
  48. that we do not make the mistake of starting to rely on them. In some
  49. cases these are the consequence of requrements; in other cases, of
  50. design choices that were not forced.</p>
  51. <dl>
  52. <dt><b>A process model is not required</b>
  53. <dd>Opera deallocates all its resources and does not rely on the
  54. operating system to clean up after process termination. This is
  55. required on MHW, where there are no processes.
  56. <dt><b>Threads are not required</b>
  57. <dd>Opera does not require threads for its interleaved operation.
  58. <dt><b>Some advanced C++ concepts are not required</b>
  59. <dd>RTTI, STL, namespaces, exceptions: we don't need them.
  60. </dl>
  61. <a name="soft">
  62. <h2>Assumptions the Core makes about the platform</h2>
  63. <p>The following assumptions do not go deep enough to define the
  64. envelope of change, but they are important for the code that we
  65. deliver today. If the platform does not meet these assumptions then
  66. significant work may be required too work around the problem.</P>
  67. <p>The following list is not complete.</p>
  68. <dl>
  69. <dt><b>Unicode</b>
  70. <dd>Since we no longer deliver Opera on any platform that does not
  71. use Unicode, we must assume it only works on Unicode platforms.
  72. <dt><b>ANSI C library</b>
  73. <dd>The core code uses the ANSI C library extensively. Support on
  74. the level of C89 is usually sufficient.
  75. <dt><b>"Reasonable" C++ compiler, linker, and library</b>
  76. <dd>Right now we are using templates, multiple inheritance, and
  77. longjmp (for LEAVE). We can probably cope with a compiler that does
  78. not have templates and multiple inheritance but it will be painful.
  79. We prefer to use longjmp for LEAVE but can handle a system that only
  80. supports exceptions.
  81. <dt><b>32-bit architecture</b>
  82. <dd>Opera currently requires a 32-bit architecture. 16-bit support
  83. was phased out in Opera&nbsp;5. Some work was done on porting
  84. Opera&nbsp;5 to the DEC Alpha, but no release ever came of this (?).
  85. It is not known that Opera currently works on a 64-bit system.
  86. <dt><b>Byte-addressable memory</b>
  87. <dd>Parts of the image code use byte addressing. (We do not require
  88. word access to non-aligned addresses, just access to individual bytes.)
  89. <dt><b>Hardware floating-point</b>
  90. <dd>Some parts of the Opera code are floating-point intensive and may
  91. work very poorly with floating-point emulation. (Examples include
  92. parts of the layout code and the ECMAScript engine.)
  93. <dt><b>IEEE double-precision floating-point</b>
  94. <dd>The ECMAScript engine requires IEEE floating point, both because
  95. the spec requires it and because there is lowlevel code in the engine
  96. that assumes this representation.
  97. <dt><b>Platform can use the Core's 3rd-party libraries</b>
  98. <dd>The Core code uses a number of 3rd-party libraries. (Lars Erik
  99. keeps a list.) Some customers don't like this, and require their
  100. replacement by Opera-written code. In many cases, a rewrite is both
  101. costly and likely to produce code that is less functional than the
  102. code that is replaced, so generally we require that the customer must
  103. accept our 3rd-party code if they want the fully operational Core.
  104. <dt><b>Hierarchical file system</b>
  105. <dd>Opera apparently requires some kind of file system for its
  106. preferences and caching. (At the time of writing, a hierarchical file
  107. system is required since Opera will not compile without such support
  108. enabled, but that at least needs to be fixed.)
  109. </dl>
  110. <hr>
  111. <h2>Candidates for inclusion in the above lists</h2>
  112. <dl>
  113. <dt><b>Graphical user interface</b>
  114. <dd>LTH believes this is now a requirement, and if so it should be added to
  115. the lists of assumptions. If not, it should be added to the list of non-assumptions.
  116. <dt><b>Reliable OS support for reliable OOM handling</b>
  117. <dd>Is this envelope-of-change or can-be-fixed-at-a-price, or both, depending on the
  118. nature of OS support?
  119. <dt><b>Nonblocking name resolution</b>
  120. <dd>Is this a requirement or just "nice to have"?
  121. </dl>
  122. </body>
  123. </html>