# -*- tab-width: 4 -*-
#
# Application domain concepts
#
# The application domain relates to the web browser in terms of what
# it does: how it obtains, processes, and displays data, and issues
# related to these activities.
#
#
# The central concept is APP.DOCUMENT, which presents an overview of
# how a document is handled; most others follow from this.
#
#
####
#
# Candidates for the application domain concepts are
#
#   Document management 
#      (Multiple windows / multiple documents / frames / iframes)
#   Document parsing
#   Document rendering (subconcepts: reflow, bidi, quirksmode, era)
#   Image decoding
#   Security models
#   Download
#   Upload
#   Cookies
#   Spatial navigation
#   Error reporting / feedback to advanced users
#	User configurability with preferences and language file?
#   The device may move, go to sleep

APP.DOCUMENT

  .def
    A "document" is a collection of content named by a URL, possibly
    referencing other URLs for embedded content and yet other URLs for
    linked and related content.

  .loading
    A document is loaded into the browser by loading data from the
    primary and embedded URLs

  .display
    The document can be interpreted by Opera or not.  In the former
    case, a document "window" is created for it and (part of) the
    document is displayed in that window.

  .commands
    A command facility allows the user to interact with the document
    or perform operations on the document windows or on non-document
    aspects of the application.

  .activation
    Documents have areas that can be activated: links can be clicked,
    text input controls can be activated, buttons can be pressed, and
    different parts of the document can be viewed by scrolling it
    within its window.

  .security
    A document's security level is a function of the protocol through
    which it was loaded and the metadata supplied through that
    protocol (eg certificates or passwords).  

    [It could also be a function of content.  Eg, a document that sets
    document.domain could have its security rating lowered.]

    [Is security level associated with eg the URL to which a POST
    goes?  Say a doc from HTTPS posts to HTTP...]

  .related
    APP.CONTENT_LOADING, APP.WINDOW

  .comments
    Note that the "display" does not need to have a physical
    realization, and that the "user" need not be a human.


APP.WINDOW

  .def

  .current

  .history
    (List of URLs)
    (Document state, eg, forms content)

  .navigation
    (Moving in the history)


APP.HISTORY



APP.CONTENT_LOADING

    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.


APP.PROTOCOL_TYPES

	Examples: HTTP, HTTPS, FILE, FTP, 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?).

	Broken http servers?
	...

APP.CONTENT_TYPES

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

    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.


APP.CONTENT_CACHING


APP.OPAQUE_CONTENT

	Applets, plug-ins, ActiveX -- these are loadable components that
	interact with Opera in limited ways, notably by displaying their
	data in an area provided by Opera, but generally run independently
	of Opera.


APP.CERTIFICATES


APP.AUTHENTICATION

	Authentication is the mechanism whereby the application user is
	required to present credentials before being allowed to load and
	view or save content from a server.


APP.RESILIENCE

	Resilience is the quality of being able to continue working,
	possibly with reduced quality in other areas, in the presence of
	some types of errors.

	Errors originate from many sources, including networks (eg lost
	connections) and disks and memory (eg capacity exceeded).

APP.PORTABILITY

    How much work to port Opera?


APP.RESPONSIVENESS

	Responsiveness is the quality of letting the user interact with
	the application at almost any time, in the sense that she can
	perform actions in the user interface and have the application
	react to these actions in some consistent and timely manner.


APP.CLIENT_SIDE_EXECUTION

	Client-side execution (JavaScript, XSLT, events)


APP.PLATFORM_ADAPTATION

    The idea here is that Opera adapts to the platform.  This can mean:
    UI standards, security mechanisms (eg correct permissions on browser
    files for privacy, or, encryption/scrambling where the platform has
    none), use of platform libraries, fonts, ...


APP.CHARSET

    Unicode is the lingua franca, but encodings abound, and the
    correct content type is not always specified.


