|Logiweb system pages|
'Loading' a Logiweb page is a process which takes a Logiweb 'reference' as input and produces a Logiweb 'cache' as output.
After loading a page it is possible to 'render' and 'execute' it.
At present, loading, rendering, and execution is done by the pyk compiler. Rendering results in a number of interlinked html-, pdf-, and other files. When viewed in an ordinary web browser, the interlinked html-, pdf-, and other files allow to navigate within and among Logiweb pages. A genuine Logiweb browser would allow the same kind of navigation as is possible with an ordinary web browser plus the interlinked html-, pdf-, and other files. Hence, an ordinary web browser plus the interlinked files effectively implement a Logiweb browser. We refer to that browser as the 'Logiweb cross browser' because it is a Logiweb browser that is hosted by an ordinary web browser.
Rendering of a Logiweb page typically results in a number of html- and pdf-files. But the rendering engine of Logiweb is not restricted to any particular format. Rendering of a Logiweb page may also result in .c files, .h files, makefiles, and any other kind of file that can be expressed as a sequence of bytes. It is the author of a Logiweb page who decides which and how many files rendering results in. In particular, rendering of a Logiweb page may result in 'Logiweb machines' which are executable files.
Loading a page consists of fetching, unpacking, codifying, and verifying the page which is described in the following.
Table of contents
A Logiweb reference is to Logiweb what a http reference is to the worldwide web: It is something that allows to locate a page.
A http reference encodes the physical location of the page (a particular file on a particular server). In contrast, a Logiweb reference is a signature which allows to locate a page with a particular contents regardless of the physical location.
If you load a Logiweb page twice, even with years in between, using the same reference, then you can be sure to receive the same page the two times. In contrast, ordinary web pages are in flux and may change at any time.
A Logiweb reference is a sequence of bytes where a byte is a cardinal (i.e. natural number) in the range 0..255 (i.e. 0 to 255 inclusive). A Logiweb refererence can be arbitrarily long but typically consists of around 30 bytes.
To see the reference of a page, click the 'Reference' entry of the crossbrowser main menu of the page and then click 'Hex bytes'.
The first activity when loading a page is to 'fetch' it. 'Fetching' a Logiweb page is a process which takes a Logiweb reference as input and produces a Logiweb vector as output.
A Logiweb vector is a sequence of bytes. The vector of a Logiweb page is the form in which Logiweb pages are stored on disc and transmitted over networks.
A Logiweb vector must either conform to the Logiweb default format or to a user defined format. In the latter case, an advanced Logiweb user must tell Logiweb how to unpack that format. As an example, one may explain Logiweb how to interpret pfb font files. After that, Logiweb can handle such files, but the files have to be prepended with about 70 bytes (two references and a dictionary) which identify the format before submission to Logiweb.
To see the vector of a page, click the 'Vector' entry of the crossbrowser main menu of the page.
The vector of a page starts with the reference of the page. Hence, if you look up both reference and vector you should see that the reference forms a prefix of the vector.
Fetching a page consists of 'locating' and 'getting' the page. 'Locating' a page is a process which takes a Logiweb reference as input and produces a uniform resource locator (url) as output. 'Getting' a page is a process which takes the url as input and produces the vector as output.
The server has four possible responses: (1) The server knows the url of the page and sends this url. (2) The server thinks that the page does not exist anywhere in the world and says so. (3) The server refers to another server by sending the url of the other server. (4) The server sends a short notice saying that it is too busy to reply at the present time.
The last of the four options is a safety valve included in the Logiweb protocol to handle denial of service attacks. That option will be ignored in the following.
When locating a page, option (3) above may occur several times: one may have to consult a chain of servers before ending in situation (1) or (2).
As mentioned, a reference is a sequence of bytes. At any time while locating a page, some of the bits of the reference are 'resolved' and some are 'unresolved'. To begin with, all bits are unresolved and, for each time situation (3) above occurs, the number of resolved bits increases. Hence, locating a page terminates after consulting at most as many servers as there are bits in the reference.
'Getting' a page is done by sending the url to an ordinary web server. Hence, Logiweb servers merely locate the page, the actual delivery is done by an ordinary web server.
The translation from reference to vector is 'univocal' in the sense that doing the translation twice yields the same result. The translation from reference to url, however, is not univocal: Identical copies of a Logiweb page may reside many different places, and the Logiweb servers just point out a random one of them.
If you depend very much on a particular Logiweb page, you should copy it to your local machine and make it available through your local Logiweb server. That way the page will continue to exist on Logiweb, even if all other copies are deleted.
The second activity when loading a page is to 'unpack' it. 'Unpacking' a Logiweb page is a process which takes a Logiweb vector as input and produces a Logiweb 'bibliography', 'cache', 'dictionary', and 'body' as output.
A Logiweb bibliography is a list of bibliographic entries where an entry is a Logiweb reference. Entry number zero (the first entry) is the reference of the page itself, so every page refers to itself.
Bibliographic entries except entry number zero are termed 'proper' entries. A bibliography may have zero, one or more proper entries. The graph that has Logiweb pages as nodes and proper entries as edges form a directed, acyclic graph.To see the bibliography of a page, click the 'Bibliography' entry of the crossbrowser main menu of the page.
To explain the notion of a 'cache' and many other Logiweb data structures, we first need to introduce the notion of a Logiweb 'array'. A Logiweb array is an associative structure which can map cardinals to arbitrary values. Logiweb arrays are organized such that the access time is logarithmic in the number of entries of the array in the cases of interest to Logiweb.
The values of an array may themselves be arrays. We shall refer to an arbitrary value as a 0-dimensional array and to an array of n-dimensional arrays as an (n+1)-dimensional array.
For an array A and a cardinal n we shall use A[n] to denote the value that A associates to n. For an e.g. 3-dimensional array B, B[u][v][w] denotes ((B[u])[v])[w].
Arrays may be sparse: an array may map e.g. 10 and 20 to values without mapping the numbers in between to anything. The access time of an array A is logarithmic in the number of indices i for which A[i] is defined.
As mentioned, when 'loading' a Logiweb reference one obtains a Logiweb 'cache'. Loading a reference is univocal, so loading a reference twice gives the same cache both times.
Loading a reference may require quite some computational resources, so it is reasonable to avoid loading the same reference twice.
The cache of a page is an array which maps cardinals to values. The cache of a page maps the cardinal 0 to the reference cardinal of the page itself. Furthermore, the cache of a page maps the reference cardinals of the page and all its transitively referenced pages to the 'racks' each each page.
The 'rack' of a page is another array which maps cardinals to values. We refer to an array of inhomogeneous data as a 'rack' and to the indices of such an array as 'hooks'. The hooks are strings like 'bibliography' and 'dictionary' converted to cardinals.
The rack of a page maps the bibliography hook to the bibliography of the page, the dictionary hook to the dictionary of the page, and so on. The rack of a page has the following hooks: