# Conceptual Framework for Opera's Architecture

I am using the conceptual framework from Software Architecture for Product Families by Jazayeri, Ran, and van der Linden to describe Opera's architecture. This entails defining scope, concerns, significant requirements, component domains, structures, views, texture, the domain concepts, and finally the architectural concepts. Of these, the architectural concepts are the most important, but it is only after tackling all the other items on the list that we can elucidate them well.

I have plagiarized some of the text from the book at the beginning of each section in order to make the description here self-contained.

## Architectural scope

Web browser application Some components of the application to be used standalone

## Architectural concerns

Portability (to a large range of systems; to be ported quickly) Scalability (from handheld devices to large workstations) Add-ons (eg support for optional add-ons for e-mail, rss, usenet, voip, ...) Some components will be used standalone (ECMAScript, HTTP stack)

## Architecturally significant requirements

???

## Component domains

## Architectural structures

## Architectural views

## Texture

- Messaging system
- OP_STATUS / OpStatus / TRAP / LEAVE; macros built on and around these
- OpAutoPtr / OpStackAutoPtr / ANCHOR
- MemoryManager::tempbuffers
- MemHand / MemElm
- OpGlobal

## Domain concepts

Application domain concepts originate in application domain analysis, they describe a web browser in terms of what it does: how it obtains, processes, and displays data, and issues related to these activities.

Implementation domain concepts on the other hand originate in implementation domain analysis, they describe the platforms that our web browsers run on: what they can and cannot do, how they behave, and the kinds of variations found.

### Application domain concepts

Protocol types

  Examples: HTTP, HTTPS, FILE, FTP, IMODE, WAP

  These and other protocols may have to be supported, depending on the system and the customer. The protocol type is relevant during content loading because it impacts how the content is processed before it is delivered (including how it is translated, whether authentication is performed, whether encryption and decryption must be performed on the content, and the kind of MIME type that is inferred if the type is missing). It is also relevant to caching, since some protocols inhibit caching (FILE, FTP, HTTPS), and to cookies, since some protocols may not set cookies (many?).

Content types

  Examples: HTML, XHMTL, XML, WML, X+V, Voice, SVG, ATVEF/DCS, Video, Audio, JPG, GIF, TIF, BMP, ICO, PNG, JavaScript

  The content type determines to whom it is delivered (to the browser or to an external agent), how the content is processed, how it is cached (different policies for different types), and also whether it must be decompressed before being consumed.

Loading of content

  The logical view of content loading is as a separate process that loads data and provides it piecemeal to a consumer when it is available, and that passes along other status information. The consumer may start processing the data when they are available, even if not all data are yet available. In the case of HTML content, links to external content (eg style sheets, images, scripts) will cause the HTML parser to start further processes to load the linked content.

  Loading tasks can be stopped before they complete, if the user stops loading.

  The loading is integrated with caching in the sense that if the requested content is in the cache then the content is delivered from the cache.

  Content lives at a specific address; the address is represented by a URL in its canonical form.

Caching of content
Browsing history
Document management (Multiple windows / multiple documents / frames / iframes)
Document parsing
Document rendering (subconcepts: reflow, bidi, quirksmode, era)
Client-side execution (JavaScript, XSLT, events)
Embedded opaque content execution (applets, plugins)
Image decoding
Certificates
Authentication
Security models
Download
Upload
Cookies
Proxies
Automatic proxy configuration
Spatial navigation
User-editable preferences
User-changeable language
Error reporting / feedback to advanced users
UI responsiveness
Resilience in the face of resource limitations

### Implementation domain concepts

Latency (as it applies to loading content and other things)
Bounded heap memory
Bounded code memory
Bounded stack
Bounded network connections
Bounded file descriptors
Poor operating systems (eg global vars, no processes, no threads, no files)
Poor libraries
Poor compilers
Poor hardware (small cache, feeble CPU, slow memory, software FP)
Poor fonts
Slow disks
Nonstandard floating point
UI technologies (mouse/pen/wheel/remote/kbd)
Display technologies
Libraries (platform/3rd party/our own)
Non-OOM safe platforms
IPV4 / IPV6
Distinguished "main thread" on some platforms

## Architectural concepts

The architectural concepts describes how application domain concepts are mapped to the implementation domain concepts: essentially, how an activity in the browser can be supported on the platforms in question.

Interleaved loading and execution based on callbacks
Listeners / callbacks in general
Async image decoding
Async disk writing / delayed disk writing
Delayed script execution
Preempted script execution
Main-thread execution of some tasks
Font switching
Pool allocation to defeat performance problems and fragmentation
Out-of-memory handling
Out-of-disk handling

## Loose ideas, notes, etc.

Note that "UI responsiveness" and "Resilience in the face of resource limitation" are application concepts, but that specific limitations that must be contended with (eg poor machines and limited memory) are implementation domain concepts.

We should add a domain string to every Feature, that states which domain the feature is in? What this will do is probably focus the feature definition, and split features that are cross-domain?