MMM : Technical characteristics

Reference documentation, standards

During the design and development of MMM, we attempted to comply to the available (or proposed) standards for Web applications. Most of these standards are defined in RFCs or recommendations from the Web Consortium:

HTML 2.0 Proposed standard (rfc 1866)
HTML 3.2 Reference specification (W3C Recommendation)
HTTP/1.0 Proposed standard (rfc 1945)
rfc1630 on Universal Resource Identifiers (rfc 1630)
rfc1738 on Uniform Resource Locators (rfc 1738)
rfc1808 on Relative URL (rfc 1808)

However, the browser is not fully compliant. Some known problems are listed below. If you find more problems, please report them to me, giving

the nature of the problem,
a relevant reference in one of the documents or some other valuable material (such as a discussion of the HTML working groups)
and an URL pointing to a document exhibiting the problem.

Warning

MMM is a lot less tolerant than most other browsers. Thus, if MMM complains about errors in a document, or doesn't display "correctly" a document according to you, whereas Mozilla or Explorer just handle it, the culprit is not necessarily MMM : it may be the document. Moreover, and I can't repeat this enough:

The implementation of tables is bogus.
The implementation of tables is bogus.
The implementation of tables is bogus.
The implementation of tables is bogus.
The implementation of tables is bogus.
The implementation of tables is bogus.
There. You've been warned.
And it's slow.
And it uses heaps of memory.

Please don't complain about tables. I strongly believe there is not proper way to support tables with the Tk toolkit, as of version 4.{0,1,2}.

Components

Architecturally speaking, the browser is formed of several relatively independent components:

communication protocols
HTML viewer
other viewers
cache

Protocols

Among the internet protocols used for the Web, MMM implements only HTTP 1.0. Other protocols are always deferred to the proxy (ftp, wais, gopher,...). Several requests can be handled simultaneously. Read and writes on the network are non-blocking, except for DNS interrogations.
For an HTTP request, the browser first attempts a direct connection to the server, and in case of failure, redirects the request to the proxy. The direct connection step never occurs if the browser is configured in mode Always Use Proxy.
Proxy authentication as proposed in HTTP 1.1 is implemented.
Vendor specific extensions of HTTP (such as : Refresh, push/pull) are not supported.
A request of type file: is interpreted as follows: if the host is "localhost" (file://localhost/path), or left unspecified (file:///path), then path is considered as an absolute path on the local file system. Note: file:/some/path is not a vlid URL, but is accepted for compatibility reason.
If the host is specified, then the URL is considered as an ftp: URL, and forwarded to the proxy.
URLS of type telnet: are not supported at all.

HTML Viewer

MMM implements an HTML viewer (documents of type text/html) conforming to HTML 2.0, and on some points to HTML 3.2. Lexical and syntactical analysis respect (in principle) the subset of SGML used in the definition of HTML, and a given DTD (HTML 2.0 or 3.2). Only SGML minimisation rules are implemented. Syntactical analysis does not check tag attributes (although the viewer has to check some of them, obviously). The capabilities of displaying in-lined images are exactly the capabilities of Tk image loading. Currently, only GIF, of MIME type image/gif (except for interlaced GIFS, animated GIFS, and an approximative treatment of transparent GIFs), PNM and XBM images formats are supported. More image formats can be supported through Tk extensions (external dynamically linked libraries). For example support for PNG and JPEF (non progressive) can be obtained through libraries. In recent versions of MMM, animated GIFs are supported with additionnal specific code

Image loading

There are several modes for image loading, configured in the Preference panels. Image loading uses an internal queue, with a limit on the maximum number of simultaneous network connections dedicated to images.

Other viewers

For other types of document (except text/plain for which there is also a builtin viewer), MMM calls metamail. A proper configuration of metamail (through the ~/.mailcap file) can provide viewers for most of document types used on the Web.

Cache

There are two cache levels in MMM : the first level is a graphical cache, where we keep the displayed version of a document. The second level is a traditional cache (in memory or on disk), where we keep document sources (only for text documents).

Known Bugs

HTML compliance problems

The following problems are known:

<!DOCTYPE> is not parsed properly. To my knowledge, none of the main browsers actually parse DOCTYPE.
<! gabuzomeu > is displayed as text (in any case, this is not a well-formed comment)
management of spaces might not be always correct.
ALIGN in <IMG> is not conformant (in particular, in HTML 3.2, the text should wrap around images. Tk doesn't allow this).
The background attribute of BODY is not handled.
The width attribute of PRE is not handled.
The enctype attribute of FORM is always equal to applications/x-www-form-urlencoded.
The type=file case in INPUT is not handled.

HTTP Protocol

Only the most used subset of HTTP/1.0 is implemented. Only the GET, HEAD and POST methods are supported.