Journal taab, une tribune sans XML

Posté par (page perso) . Licence CC by-sa.
Tags :
22
27
avr.
2017

Bonjour Nal,

Je t'écris pour te faire part de la release de taab, un nouveau moteur de tribune basé sur vue.js, pegjs, blazecss and php (désolé).

Les fritures de ce bouchot:

  • sans XML, car le backend est conforme à la nouvelle norme coutume de la moulosphère: le TSV.
  • des norloges ISO 8601 ( YYYY-MM-DDTHH:mm:ss )
  • gestion du paramètre lastId et de l'entête X-Post-Id.

Pour ceux qui se demandent ce qu'est une tribune, un bouchot, un backend XML & co, il s'agit du vocabulaire de la moulosphère, un ensemble de systèmes de messageries semi instantanées orientées vers l'incubation d'excellence, l'innovation disruptive et l'insoumission de la France.

La plus fréquentée est celle de linuxfr, mais il en existe beaucoup d'autres: les meilleures accessibles avec mon autre projet moulesque, jb3.

++ Nal

  • # Beau travail

    Posté par . Évalué à 9.

    Simple et épurée j’aime beaucoup.

    Comme ton autre projet de « web palmiped multipiling », jb3, celui-ci semble être de grande qualité.

    Tout d’abord le lien vers les sources : https://github.com/devnewton/taab , tu l‘as oublié. J’irai voir, j’aurais certainement certaines réponses aux interrogations qui suivent.

    PHP: Il ne faut pas avoir honte, c’est un langage qui a ses avantages. Pourquoi ce choix ? À cause de l’hébergement ? Je vois que tu utilises nginx, couplé à uWSGI tu pourrais utiliser un langage de bien meilleure facture que PHP.

    Petite remarque, tu devrais ajouter une entête HTTP "Last-Modified" à tes réponses, ça permet de checker ton bouchot et télécharger le contenu seulement si cela est nécessaire (en envoyant soi-même l’entête "If-Modified-Since"…)

    Est-ce que ton moteur de tribune fait du stockage (j’imagine au moins à court terme) ? Tu utilises quelle méthode ?

    Voilà. Happy mouling!

    • [^] # Re: Beau travail

      Posté par (page perso) . Évalué à 3.

      PHP: Il ne faut pas avoir honte, c’est un langage qui a ses avantages. Pourquoi ce choix ? À cause de l’hébergement ? Je vois que tu utilises nginx, couplé à uWSGI tu pourrais utiliser un langage de bien meilleure facture que PHP.

      Taab est né pour illustrer le passage à vue.js d'une vieille appli en PHP. Personne n'aurait l'idée de démarrer un nouveau logiciel avec ce langage en 2017!

      Est-ce que ton moteur de tribune fait du stockage (j’imagine au moins à court terme) ? Tu utilises quelle méthode ?

      Non, mais c'est assez facile à ajouter:

      • en ajoutant une double écriture backend.tsv / archive.tsv directement dans le post.php
      • en appliquant un logrotate sur le fichier backend.tsv
      • en utilisant un archiveur de tribune (c'est la solution que j'ai choisi: j'utilise tout simplement jb3)

      Incubez l'excellence sur https://linuxfr.org/board/

      • [^] # Re: Beau travail

        Posté par . Évalué à 1.

        Personne n'aurait l'idée de démarrer un nouveau logiciel avec ce langage en 2017!
        Bah si moi ! :)

    • [^] # Re: Beau travail

      Posté par (page perso) . Évalué à 3.

      Petite remarque, tu devrais ajouter une entête HTTP "Last-Modified" à tes réponses, ça permet de checker ton bouchot et télécharger le contenu seulement si cela est nécessaire (en envoyant soi-même l’entête "If-Modified-Since"…)

      Le paramètre lastId assure cette fonction. Pour être plus conforme au HTTP, il faudrait plutôt utiliser ETag non?

      J'ai voulu faire une tribune normale pour pouvoir tester avec des coincoins du marché, mais sur le fond:

      • les ids des posts ne servent à rien.
      • la distinction login/info n'a aucun sens pour une tribune sans authentification.
      • le lastId devrait être du ETag.

      Incubez l'excellence sur https://linuxfr.org/board/

      • [^] # Re: Beau travail

        Posté par . Évalué à 2. Dernière modification le 28/04/17 à 10:34.

        Le paramètre lastId assure cette fonction. Pour être plus conforme au HTTP, il faudrait plutôt utiliser ETag non?

        Oui c’est peut-être mieux. Mais les entêtes dont je parle semble être bien supportées. Ça marche avec les boards linuxfr et euromussels.

        les ids des posts ne servent à rien.

        Je ne suis pas d’accord. Couplés aux norloges ils permettent de déterminer le bouchot d’origine avec un taux d’incertitude assez faible.

        On peut utiliser le couple (id, norloge) comme identifiant unique d’un post dans la moulosphère. (avec quelques risques de collision c’est sûr, j’ai du mal à l’évaluer…)

        le lastId devrait être du ETag.

        Oui. Ou au moins ajouter l’entête Last-Modified. En PHP ça devrait pas être trop compliqué…

        Je vais regarder côté nginx comment c’est géré, et si on peut pas lui faire ajouter automatiquement l’entête Last-Modified selon l’âge du fichier par exemple.

        • [^] # Re: Beau travail

          Posté par (page perso) . Évalué à 4.

          Je ne suis pas d’accord. Couplés aux norloges ils permettent de déterminer le bouchot d’origine avec un taux d’incertitude assez faible.

          Le post étant récupéré depuis un backend, pourquoi chercher une corrélation tordu? Un post vient de dlfp parce que tu l'as trouvé dans le backend de dlfp.

          Oui. Ou au moins ajouter l’entête Last-Modified. En PHP ça devrait pas être trop compliqué…

          Tu peux aussi exposer le fichier data/backend.tsv directement et laisser ton serveur web gérer le caching.

          Incubez l'excellence sur https://linuxfr.org/board/

          • [^] # Re: Beau travail

            Posté par . Évalué à 3. Dernière modification le 28/04/17 à 13:07.

            Tu peux aussi exposer le fichier data/backend.tsv directement et laisser ton serveur web gérer le caching.

            Je compte exposer directement le fichier. Je ne comprends pas à quel caching tu fais allusion…

            Si je fais un GET sur l’url sans spécifier If-Modified-Since dans l’entête (ou utiliser un ETag) le serveur doit me renvoyer le contenu, que celui-ci ait changé ou pas… et je ne peux pas trop envoyer moi-même cette entête car je n’ai pas de Last-Modified répondu par le serveur (je sais pas trop quelle date mettre…).

            Je fais donc un HEAD afin d’avoir juste les entêtes pour savoir si je dois faire un GET pour avoir le contenu ou bien ce n’est pas la peine (dans ce cas je prends mon cache local).

            Mais bon. J’ai l’impression que je me prends la tête pour rien et que ça aurait du sens de procéder ainsi si le contenu faisait 4km de long… mais là, limite, je ferais peut-être mieux de récupérer le contenu à chaque fois…

            Le post étant récupéré depuis un backend, pourquoi chercher une corrélation tordu? Un post vient de dlfp parce que tu l'as trouvé dans le backend de dlfp.

            J’ai besoin d’une clé primaire pour mes posts, tous bouchots confondus. Pourquoi ? Parce que je pourrais très bien checker deux fois le même backend, pour une raison X ou Y, checker un historique de backend… importer/exporter des posts d’un backend à un autre…

            Du coup, comme je maîtrise LaRache© j’utilise la puissance d’un moteur SQL à coup de 'INSERT OR IGNORE …', et deux entiers (id et time) comme clé primaire c’est parfait.

            J’ai un champ « nom de backend » mais il ne sert pas de clé. Parce qu’il est personnel (ie: j’aurais pu l’appeler 'dlfp' ou bien 'linuxfr', etc…)

            Je prends un exemple, mettons que j’ai pas d’id :

            20170205123355 Mozilla… Mussel _o/

            c’est un utilisateur authentifié nommé "Mussel", mais on ne sais pas sur backend il est authentifié…

            Si j’ai l’id correspondant je peux vérifier que ça correspond au Mussel de tel ou tel backend…

            Et puis… de toutes façon… l’id sert, au minimum, à différencier deux ou plus posts dans la même seconde, sur un même backend :) On pourrait différencier les posts avec les autres champs mais ça me paraît moins bien. L’id il est valorisé par le moteur de base de données (et éventuellement les admins du backend), pas par les entrées utilisateurs…

            • [^] # Re: Beau travail

              Posté par (page perso) . Évalué à 3.

              Je n'ai pas tout compris, mais j'ai l'impression que tu utilises le post id pour faire cradement ce que tu pourrais proprement :-)

              Quelles fritures cherches-tu à implémenter?

              Incubez l'excellence sur https://linuxfr.org/board/

              • [^] # Re: Beau travail

                Posté par . Évalué à 2.

                Quelles fritures cherches-tu à implémenter?

                Toutes !

                Pour l’instant c’est avoir un backend fédéré des bouchots sur lequel je pourrais me baser pour de futures fritures à forte valeur ajoutée.

                Ça marche bien, là c’est en test. Mais pour l’instant ce backend fédéré n’est pas servi.

                J’ai déjà un autre projet qui, entre autre, enregistre des tribunes, Zir… (ne cherche pas sur Wikipédia…). J’avais fait un script shell vite fait pour visualiser différentes stats… du coup j’ai ajouté la tribune bci

                • [^] # Re: Beau travail

                  Posté par (page perso) . Évalué à 2.

                  Tu devrais peut être utiliser des technos adaptés à la collecte et à l'analyse de donnée pour ça?

                  https://www.elastic.co/fr/products ?

                  Incubez l'excellence sur https://linuxfr.org/board/

                  • [^] # Re: Beau travail

                    Posté par . Évalué à 3. Dernière modification le 28/04/17 à 15:27.

                    C’est overkill et pas KISS du tout.

                    Si j’arrive à 52304100 myons de post j’y penserais ;)

  • # lien cassé?

    Posté par (page perso) . Évalué à 3.

    Le premier lien https://taab.bci.im/ renvoie une 502

  • # XML considered harmful ?

    Posté par . Évalué à 3.

    De toute façon, gocoincoin/goboard va rafler le marché des coincoins dès sa sortie …

  • # Mise en prod’

    Posté par . Évalué à 3.

    J’ai testé l’installation de taab, sur un mutualisé OVH, rien à dire, ça marche out-of-the-box !

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.