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.
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.
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?).
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.
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.
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.
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?