Suivi — Tribune Backend TSV pour la tribune

#1634 PostĂ© par (site web personnel) . État de l’entrĂ©e : corrigĂ©e. AssignĂ© Ă  Bruno Michel. Licence CC By‐SA.
Étiquettes :
7
19
juil.
2016

Objectif

Proposer une alternative simple et légÚre au backend xml.

Spécification

Le backend TSV:

  1. est encodé en est UTF-8
  2. est servi en text/tab-separated-values
  3. les tags du message ne sont pas XML-encodés
  4. n'a pas d'entĂȘte : son format est fixe
  5. a pour url: https://linuxfr.org/board/index.tsv
  6. a pour format: ${id}\t${time}\t${info}\t${login}\t${message}\n Note: les caractĂšres de contrĂŽle sont Ă  bannir du contenu de chaque champ. Note 2: les id doivent ĂȘtre croissant, du plus ancien au plus rĂ©cent.

  • # question

    PostĂ© par . ÉvaluĂ© Ă  2 (+0/-0).

    Ca manque de finesse dans les spécifications.

    • Comment seraient encodĂ©s les retours Ă  la ligne ou les tabulations dans les champs message ?
    • C'est censĂ© rĂ©pondre Ă  quel problĂšme ?
    • C'est quoi le problĂšme avec le XML ?
    • Pourquoi TSV et pas JSON, qui est largement plus supportĂ© ?
    • Quels sont les tags qui doivent ĂȘtre interprĂ©tĂ©s par les clients ?
    • La balise a est-elle utilisĂ©e pour les urls ?
    • Pourquoi ?

    • [^] # Re: question

      PostĂ© par (site web personnel) . ÉvaluĂ© Ă  3 (+0/-0).

      Comment seraient encodés les retours à la ligne ou les tabulations dans les champs message ?

      Pas. Comme un message de tribune est rendu comme du html, les \n, \t et espaces, ou toute chaßne constituée de ces caractÚres en nombre et combinaison quelconques, sont rendus par un espace simple. Par conséquent c'est au moteur de tribune de "sanitizer" le message en ce sens dans le backend tsv, comme il le fait déjà pour les tags.

      C'est censé répondre à quel problÚme ?
      C'est quoi le problĂšme avec le XML ?
      Pourquoi TSV et pas JSON, qui est largement plus supporté ?

      Tu arrives longtemps aprĂšs le dĂ©bat, mais c'est vrai que tu ne frĂ©quentes plus les tribunes oĂč ces discussions ont lieu.
      La réponse à tout cela est simplement "simplicité, légÚreté et robustesse". Pourquoi se lancer dans un parsing complexe quand un split("\n") suffit à récupérer les posts et un split("\t") les champs du post ?
      Le XML, outre qu'il est lourd à parser, comporte la problématique du double niveau de namespace entre les tags du backend et ceux du message, ce qui fait qu'il n'y a pas 2 moteurs de tribune le gérant de façon identique (tags encoded, not encoded, raw, encapsulation CDATA...)
      Le JSON est particuliÚrement adapté pour un client web, mais des coincoins sont toujours développés en client lourd.
      Et enfin, le sujet n'est pas d'éliminer les backends XML ou JSON qui ont toujours leur légitimité. Il s'agit de proposer une alternative et de laisser le choix au client.

      Quels sont les tags qui doivent ĂȘtre interprĂ©tĂ©s par les clients ?
      La balise a est-elle utilisée pour les urls ?

      Hors-sujet, il n'y a pas de changement dans le format du contenu du message (si ce n'est la suppression des \n \t, ce que la plupart des moteurs fait déjà). La demande ne concerne que le format du backend.

      Pourquoi ?

      Je profite de cette derniÚre question plutÎt large pour aborder d'autres points : on voit que le but premier d'un tel backend est l'efficacité, et celle-ci prend tout son sens lorsque le format TSV est couplé aux autres techniques d'optimisation : renvoi uniquement des posts utiles grùce au paramÚtre last-id, posts ordonnés par id croissant (permettant au client d'insérer tous les nouveaux posts d'un coup sans trier), support du XPOST pour économiser un get aprÚs un post, etc.

      Bien cordialement,
      Rock Hightram
      Mouling Technologies Senior Architect

  • # Pull request

    PostĂ© par (site web personnel) . ÉvaluĂ© Ă  3 (+0/-0).

    Pour info, j'ai fait une pull request pour ça, ici :

    https://github.com/linuxfrorg/linuxfr.org/pull/214

    Je l'ai testée en local, ça marche au moins avec wmcc et dcoincoin.

Envoyer un commentaire

Suivre le flux des commentaires

Note : les commentaires appartiennent Ă  celles et ceux qui les ont postĂ©s. Nous n’en sommes pas responsables.