# Architectural Overview

Before starting on the design phase of an application, it is advantageous to get an overview of the fundamental concepts of the Library and how it interacts with an application. Largely, it is divided into four different categories of functions as indicated in the figure:

Core Entity
  This is the fundamental part of the Library. The core entity is not a closed entity but an open frame construction that provides hooks for the dynamic modules. It consists of an access manager, a thread manager, a stream manager, a cache manager and some fundamental data structures. The contents of the core entity is except for some major entry points largely internal to the Library but the hooks are public and initialized dynamically. Many of the sections through out this paper contain references to the core entity and explain the interaction between the core entity and an application.
Dynamic Modules
  The dynamic modules can be enabled or disabled dynamically during execution of an application. They consist of a set of converter streams and protocol modules which are explained in the sections Access Methods and Stream Interfaces. There are several ways to initialize the dynamic modules:
  1. Through a configuration file (often called a rule file) which is parsed at start up time
  2. Using static initialization functions which are created at compile time
  3. By initializing the modules during execution as the application requires it
  The Library has a set of default, static initialization functions which can be found in the HTInit module. By default they enable all the dynamic modules in the Library, but this can be changed as described later.
Application Specific Modules
  These modules are often specific for client applications including functions that require user interaction, management of history lists etc. The default implementation of these modules in the reference code is often simple and intended for simple character based applications like the Line Mode Browser and more advanced clients will often have to override them. That is, a module with an identical interface is provided by the application, and the loading of the defailt module suppressed. This is explained in detail in the sections Keeping Track of History and User Prompts and Confirmations.
Generic Modules
  The Library provides a large set of generic utility modules such as various container classes, parsing modules etc. These modules are characterized by being public available to the application programmer so that they easily can be used in the application. They consist mainly of three different types of modules:
  Container Modules
    Modules that support various types of memory management
  URI Management
    Code for parse, canonicalize, encode, and decode a URL
  Basic Utilities and Macro Definitions
    These modules contain a large set of macros in order to make the code more portable
  The reader is referred to the Internals and Programmer's Guide for a detailed description of these modules.

The Library contains many data structures of which most are for internal only and will not normally be referenced directly from outside the Library. However, as the definition of a graphic object is done by the application and not by the Library, a the following figure gives a quick overview of the three most important data structures (or objects) and how they are interconnected.

HTRequest structure
  The `request` structure contains information intended for the client application, the server application and for the Library itself for how to fulfill a request. The default values of the structure are appropiate for a client loadinf a document from either an anchor or a URI. Managing `requests` is described in section The Request Object
HTAnchor structure
  Anchors represent any objects which may be the sources or destinations of hypertext links. Anchors contain all information about the object, whether it has been loaded, known metainformation about the object (language, media type etc.), and relations to other objects. Managing `anchors` is described in section The Anchor Object
HyperDoc structure
  The `HyperDoc` structure is only declared in the Library - the definition is left to the client application. For the Line Mode Browser, it is defined in the GridText Module where it is called `_HText`. It contains all information needed to present and manage a graphic object. The client is responsible for allocating and freeing all `graphic objects` which may entail tradeoffs of speed versus available resources. When the object is freed, the link from the `anchor structure` must be put to `NULL`. The dotted line symbolizes that it is free for the client to create a `HyperDoc` object including a link to the `request` structure.