Caractéristiques techniques de MMM

Documents de références, standards

Le développement de MMM a été dicté par le respect des différents standards en vigueur ou proposés pour les applications Web. Ces standards sont pour la plupart définis par des RFCs ou des recommandations du Consortium Web :

HTML 2.0 Proposed standard (rfc 1866)
HTML 3.2 Reference specification (W3C Recommendation) REC-html32.html
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)

Toutefois, il faut noter que le butineur MMM n'est pas toujours conforme à ces spécifications. Quelques lacunes connues sont décrites ci-dessous. Si vous trouvez d'autres cas de non-respect des standard, merci de me les rapporter, en donnant si possible

la nature du problème,
un pointeur précis vers la spécification correspondante, ou autre référence (comme une discussion du Working Group HTML ou un avis d'autorité)
un document (ou une URL pointant sur un document) qui met le problème en évidence.

Attention

MMM est beaucoup moins tolérant que les autres navigateurs pour les documents incorrects. Aussi, si MMM se plaint d'erreurs dans un document ou n'affiche pas ce document correctement selon vous, alors que Mozilla ou Explorer ne disent rien, le coupable n'est pas forcément MMM, ce peut être le document. De plus, et ca ne sera jamais assez répété:

L'implantation des tables est boguée.
L'implantation des tables est boguée.
L'implantation des tables est boguée.
L'implantation des tables est boguée.
L'implantation des tables est boguée.
L'implantation des tables est boguée.
L'implantation des tables est boguée.
L'implantation des tables est boguée.
Voilà. Vous êtes prévenus.
Et en plus elle est lente.
Et elle consomme beaucoup de mémoire.

Merci de ne pas vous plaindre au sujet des tables. Je crois sincèrement qu'il n'y a aucun moyen de les supporter correctement avec la version courante de Tk (4.2).

Composants

Logiquement parlant, le butineur est formé de plusieurs composants relativement indépendants.

protocoles de communication
afficheur HTML
autres afficheurs
cache

Protocoles

Dans la famille des protocoles TCP/IP utilisés pour le Web (globalement parlant), MMM n'implémente que HTTP 1.0. Les requêtes pour d'autres protocoles (ftp, wais, gopher) sont redirigées vers le proxy. Plusieurs requêtes peuvent être gérées simultanément. Les lectures et écritures sur le réseau ne sont pas bloquantes, à l'exception de l'interrogation du DNS.
Pour une requête HTTP, le butineur tente d'abord une connexion directe vers l'hôte, et, en cas d'échec, redirige la requête vers le proxy. L'étape de connexion directe n'a pas lieu si le butineur est configuré en mode Always Use Proxy.
L'authentification au niveau du proxy, proposée dans HTTP 1.1 est implantée.
Les extensions spécifiques du protocol HTTP, proposées par certains vendeurs (ex: Refresh, push/pull) ne sont pas supportées.
Une requête de type file: est interprétée comme suit: si l'hôte est "localhost"(file://localhost/path), ou laissé non spécifié (file:///path), alors path est considéré comme un chemin absolu sur le système de fichiers local. Note: file:/some/path n'est pas une URL valide, mais pour des raisons de compatibilité, est quand même acceptée. Si l'hôte est spécifié, alors l'URL est considérée comme une URL pour le protocle FTP et traitée en conséquence.
Les requêtes de type telnet: ne sont pas supportées.

Afficheur HTML

MMM implémente un afficheur HTML (documents de type text/html), conforme à HTML 2.0, et sur quelques points à HTML 3.2. L'analyse lexicale et syntaxique de HTML se fait en respect (en principe) de SGML (sous ensemble utilisé par les standards HTML) et des DTD respectives de HTML 2.0 et HTML 3.2. Seules les règles de minimisation de SGML sont utilisées. L'analyse syntaxique ne vérifie pas les attributs des balises (l'afficheur par contre en vérifie naturellement certains). La capacité d'afficher des images in-line est exactement déterminée par les types d'images supportés par Tk. Actuellement, Tk sait charger des images GIF, de type MIME image/gif, (sauf les GIF interlacés et les GIF animés, et avec un traitement approximatif des GIF transparents), les images PNM et XBM. Des extensions de Tk sous forme de bibliothèque partagées chargées dynamiquement peuvent permettre l'affichage de nouveaux formats d'image. Actuellement, il est ainsi possible de charger des images PNG et JPEG (non progressives, et autres restrictions). Dans les versions récentes de MMM, les GIFs animés sont supportés grâce à une gestion spéciale.

Chargement des images

Il existe plusieurs mode de chargement des images, configurable dans les Préférences. Le chargement des images se fait par une file d'attente, avec une limite sur le nombre maximum de connexions réseaux réservées aux images in-line.

Autres afficheurs

Pour les autres types de documents (hormis text/plain pour lequel il existe également un afficheur interne), MMM fait appel à metamail. Une configuration correcte de metamail, à travers le fichier ~/.mailcap, permet de visualiser correctement la plupart des documents présents sur le Web.

Cache

Il existe deux niveaux de cache dans MMM: le premier niveau est un cache graphique, qui consiste à garder un certain nombre de documents affichés par fenêtre du navigateur en réserve. Le deuxième niveau est un cache en mémoire, qui garde un certain nombre de documents, uniquement de type text/html.

Bugs connus

Non respect des standards HTML

Les problèmes suivants sont connus

<!DOCTYPE> n'est pas analysé conformément aux règles SGML. A ma connaissance, aucun des principaux butineur ne traite DOCTYPE correctement.
<! gabuzomeu > est affiché comme du texte (en tout état de cause, ce n'est pas un commentaire bien formé)
il est possible que la gestion des espaces ne soit pas toujours correcte.
ALIGN dans <IMG> n'est pas conforme (en particulier, dans HTML 3.2, le texte devrait s'"enrouler" autour des images. Tk ne permet pas de le faire facilement).
L'attribut background de BODY n'est pas traité.
L'attribut width de PRE n'est pas traité.
L'attribut enctype de FORM est toujours égal à applications/x-www-form-urlencoded.
Le case type=file de INPUT n'est pas traité.

Protocole HTTP

Seul le sous-ensemble le plus communément utilisé de HTTP/1.0 est implémenté. Seules les méthodes GET, HEAD and POST sont supportées.