Opera Core: Envelope of change

$Id$

Fundamental constraints in the Core

One sometimes talks about the "envelope of change" of a system to refer to the the fundamental constraints of the system: those assumptions that it could be very costly to change generally. What is outside the envelope is hard to attain; what is inside is already accounted for in the architecture and can be implemented in a straightforward way.

A typical example of something that was outside the envelope of change is the out-of-memory handling introduced in Opera 6--it affected virtually every line of core code and was quite costly to implement. The result is a product that is deeply different than the one we started with.

The following list is not complete.

Single-threaded execution of core code
The core code assumes that it always executes in a critical section; supporting multithreaded execution would be a large undertaking.
Floating-point support is required
Some modules must be substantially reengineered if floating-point support is not available at all. (One example is the ECMAScript engine; no doubt there are other modules, which we will document here.)
C++ is required
It sounds silly even to mention it, but we do require C++ to be supported. Not every interesting platform has C++.
Not designed for plug-and-play external components
A number of components in Opera are deeply embedded in the overall working of the browser and cannot easily be replaced by external components, at least not while leaving the feel of the system intact. Among other things, this could be because typical external components do not fit in our interleaved reading-parsing-layout mechanism.

Non-constraints in the Core

Some things are explicitly not required and are documented here so that we do not make the mistake of starting to rely on them. In some cases these are the consequence of requrements; in other cases, of design choices that were not forced.

A process model is not required
Opera deallocates all its resources and does not rely on the operating system to clean up after process termination. This is required on MHW, where there are no processes.
Threads are not required
Opera does not require threads for its interleaved operation.
Some advanced C++ concepts are not required
RTTI, STL, namespaces, exceptions: we don't need them.

Assumptions the Core makes about the platform

The following assumptions do not go deep enough to define the envelope of change, but they are important for the code that we deliver today. If the platform does not meet these assumptions then significant work may be required too work around the problem.

The following list is not complete.

Unicode
Since we no longer deliver Opera on any platform that does not use Unicode, we must assume it only works on Unicode platforms.
ANSI C library
The core code uses the ANSI C library extensively. Support on the level of C89 is usually sufficient.
"Reasonable" C++ compiler, linker, and library
Right now we are using templates, multiple inheritance, and longjmp (for LEAVE). We can probably cope with a compiler that does not have templates and multiple inheritance but it will be painful. We prefer to use longjmp for LEAVE but can handle a system that only supports exceptions.
32-bit architecture
Opera currently requires a 32-bit architecture. 16-bit support was phased out in Opera 5. Some work was done on porting Opera 5 to the DEC Alpha, but no release ever came of this (?). It is not known that Opera currently works on a 64-bit system.
Byte-addressable memory
Parts of the image code use byte addressing. (We do not require word access to non-aligned addresses, just access to individual bytes.)
Hardware floating-point
Some parts of the Opera code are floating-point intensive and may work very poorly with floating-point emulation. (Examples include parts of the layout code and the ECMAScript engine.)
IEEE double-precision floating-point
The ECMAScript engine requires IEEE floating point, both because the spec requires it and because there is lowlevel code in the engine that assumes this representation.
Platform can use the Core's 3rd-party libraries
The Core code uses a number of 3rd-party libraries. (Lars Erik keeps a list.) Some customers don't like this, and require their replacement by Opera-written code. In many cases, a rewrite is both costly and likely to produce code that is less functional than the code that is replaced, so generally we require that the customer must accept our 3rd-party code if they want the fully operational Core.
Hierarchical file system
Opera apparently requires some kind of file system for its preferences and caching. (At the time of writing, a hierarchical file system is required since Opera will not compile without such support enabled, but that at least needs to be fixed.)

Candidates for inclusion in the above lists

Graphical user interface
LTH believes this is now a requirement, and if so it should be added to the lists of assumptions. If not, it should be added to the list of non-assumptions.
Reliable OS support for reliable OOM handling
Is this envelope-of-change or can-be-fixed-at-a-price, or both, depending on the nature of OS support?
Nonblocking name resolution
Is this a requirement or just "nice to have"?