Le backend

Il y a quelques temps, je me suis amusé à écrire un schéma xml pour le backend.

Il se trouve ici : <a href="http://patlenain.dyndns.org/bouchot/tribune-1.0.xsd" title="http://patlenain.dyndns.org/bouchot/tribune-1.0.xsd">http://patlenain.dyndns.org/bouchot/tribune-1.0.xsd</a>

Aux dernières nouvelles, le schéma est correct mais on peut sûrement l'améliorer.

Et comme l'a dit un ancien président, Au revoir !

Si je puis me permettre, j'ai quelques suggestions pour la version 1.1:

1. Mettre des attributs facultatifs à la balise <board>
   • Attribut autoconfig qui contient l'URL d'autoconfiguration de la tribune
   • Attribut name qui contient le nom de la tribune
   • Attribut date qui contient la date de génération du fichier, probablement au même format que les autres dates
   • Attribut format qui indique si les messages sont structurés en XML ('XML') ou bien sont encodés ('encoded'). Pour toutes les tribunes en PHP qui n'utilisent pas un parser XML, on a un trou dans le slip dès que le XML est mal formé, et il est beaucoup plus simple pour eux de coller tout le message dans un CDATA, de vérifier qu'il n'y a pas de ]]> dedans plutot de tenter de valider le message à coup de regex. Ceci améliorerait grandement la solidité des slips. En prime, c'est la méthode utilisée dans les flux RSS.
   • Rendre site facultatif, je ne pense pas qu'il serve à quelque chose
2. Permettre comme précisé plus haut que le code logique du message, et ses balises, soit intégré dans le texte, via des entitées <a> évitant de casser le slip dans le cas ou le message est malformé d'un point de vue XML.
   soit on a en XML: <message>00:00:20 _o/ <b>* BLAM</b></message>
   soit on a en encoded: <message>00:00:20 _o/ &lt;b&gt;* BLAM&lt;/b&gt;</message>
   qui peut aussi s'écrire (c'est magique et bien pratique en PHP) <message><![CDATA[00:00:20 _o/ <b>* BLAM</b>]]></message>
   ces deux dernières méthodes ne posent pas de problème dans le cas ou le message est mal formé du point de vue XML. Une autre évolution, peut-être pas indispensable dans un premier temps, est de passer les balises contenues dans le message dans un autre namespace XML, à discuter, sémantiquement c'est quelque chose de différent, mais ça ne va pas nous facilier le boulot
3. Ajouter des balises dans les messages, qu'elles soient présentes directement dans l'arbre ou encoded :
   • ref id=... board=... qui introduit une référence/horloge vers un poste précédent éventuellement sur une autre horloge. board est facultatif et donne l'URL d'un autre backend (au passage, on spécifie que l'identifiant d'une tribune est l'URL de son backend). id est l'ID du poste référencé, ce qui donne par exemple <message><ref id='42001'>00:00:20</ref> _o/ <b>* BLAM</b></message>. De plus en plus, on est obligé d'identifier les horloges coté serveur ou coté client web pour pouvoir faire du highlight sur du :hover CSS, ceci simplifie donc le boulot puisque le backend contient déjà les liens des horloges vers les posts concernés.
   • wiki qui pointe vers une définition dans un wiki ou vers le dictionnaire des moules, on peut peut-être utiliser dfn ou une autre balise déjà définie dans xhtml...
   • img src=... alt=... pour insérer une image, un smiley

Vala

Ces commentaires sur les IDs me font penser à un autre mécanisme qu'il est possible d'implémenter dans les canards.

Les deux principaux canards envoient un entête IF-MODIFIED-SINCE qui contient la date du dernier message reçu. Cet entête est normalisé au niveau HTTP et peut être utilisé de deux façons par les canards:

• Lorsque le backend est statique, le serveur réponds "304 Not Modified" s'il n'y a pas de message, sinon il retourne le fichier.
• Lorsque le backend est dynamique, le serveur réponds également 304 lorsqu'il n'y a pas de message, dans le cas contraire, il peut ne remonter que les nouveaux messages depuis le dernier reçu par le canard.

La gestion des messages par date n'est pas très pratique, il faut sans cesse adapter le format et le parser, il est différent dans les entêtes HTTP, dans le backend et dans la base de donnée. Les horloges ne sont pas forcément synchronisées, il se pose le problème lors du changement d'heure, avec les fuseaux horaires, et une date représente toujours un interval correspondant à sa précision rendant l'information imprécise.

L'idée est de reprendre le mécanisme en se basant sur l'ID du dernier message reçu. L'entête "X-NOT-BEFORE-ID: n" est ajouté à la requête et 'n' indique l'ID du dernier message connu du canard, l'entête peut être absent ou égale à 0 dans le cas du démarrage. Si le backend est dynamique, la présence de cet entête permet de ne transmettre au canard que les nouveaux messages entrainant une importante économie de bande passante.

Sa présence n'est pas incompatible avec IF-MODIFIED-SINCE.