Suivi — Notifications pubsubhubbub

#1005 Posté par  (site web personnel) . État de l’entrée : ouverte.
Étiquettes :
6
18
sept.
2012

Suite à ma question sur le forum, je me suis mis en tête d'implémenter la notification pubsubhubbub des contenus de linuxfr.org.

Mon patch se décompose en deux parties :

  • La partie interne, qui se contente de remplir la db Redis utilisée par le site avec un Set, qui contient les urls à publier : lien github de la comparaison

  • La partie externe, un script ruby qui tourne en rond, lit les urls à publier et les publie: lien github

Il y a une astuce pour ne pas faire une boucle simplette: j'utilise la commande blpop, qui bloque la boucle lorsque la cible est vide. Celle-ci va être remplie par la notification dans rails.

J'ai préféré faire un script externe, pour ne pas alourdir le site, pour ne pas le faire planter si quelque chose ne passe pas, parce que de toute façon je pensais utiliser Redis pour avoir une sorte de persistance au cas où le script plante, et surtout pour pouvoir réutiliser ce script dans d'autres circonstances (notifications pour l'admin, améliorations avec des emails, utilisation pour un autre site web,…)

Pour le moment, seuls les Commentaires sont modifiés. Je pense qu'il est plus sage de se limiter à cela pour le moment, voir comment ça se passe, et étendre ça aux Journaux et aux News plus tard (mais vous comprendrez en voyant le diff que c'est très simple)

Testé sur la dernière version du site, sur les commentaires.

  • # Rapide avis

    Posté par  (site web personnel) . Évalué à 4 (+0/-0).

    J'ai jeté un coup d’œil rapide sur le code et il y a deux choses qui me gênent :

    • ça utilise le scripting lua de redis, or la version de redis qui tourne actuellement sur LinuxFr.org ne prend pas en charge cette fonctionnalité ;

    • ça passe par le hub de google, alors que l'on essaye d'éviter les services centralisés, tout particulièrement ceux de grosses sociétés pas très respectueuses de la vie privée de ses utilisateurs.

    Sinon, c'est sympa d'avoir proposé un patch et il a l'air plutôt bien codé, donc ça devrait pouvoir se mettre en place rapidement :-)

    • [^] # Re: Rapide avis

      Posté par  (site web personnel) . Évalué à 3 (+0/-0).

      Merci pour le retour.

      ça utilise le scripting lua de redis, or la version de redis qui tourne actuellement sur LinuxFr.org ne prend pas en charge cette fonctionnalité ;

      C'est "prévu" : le script tente d'utiliser le code lua, et passe par le code ruby si ce n'est pas possible. C'est possible grâce au bloc begin, qui va tomber dans le cas rescue si la commande eval n'existe pas sur le serveur. Le jour où le serveur évoluera, le script marchera.

      D'ailleurs, le site officiel de Redis dit qu'il ne serait pas impossible que les transactions deviennent un jour obsolètes, en faveur des scripts lua. Je me prépare à l'avenir =]

      ça passe par le hub de google, alors que l'on essaye d'éviter les services centralisés,

      Judicieuse remarque, mais :

      • On ne perd strictement aucune fonctionnalité, et il n'y a aucune dépendance. Si le hub tombe, l'aggrégateur RSS peut toujours poller le flux directement chez LinuxFr.org
      • On peut définir autant de hubs que l'on veut (solution partielle, mais potentiellement gratuite : SuperFeedr et Ayup! fournissent un service de publication qui ne coûte rien)
      • LinuxFr.org peut avoir son propre hub (ça demanderait quand même du développement et des ressources à l'utilisation, certes)

      tout particulièrement ceux de grosses sociétés pas très respectueuses de la vie privée de ses utilisateurs.

      Il s'agit là de flux publiquement accessibles à n'importe quel passant, la vie privée de personne n'est en jeu. Et puis, si Google peut indexer les flux concernés quand on lui dit qu'il y a du nouveau contenu au lieu de poller constamment le site, ça peut être intéressant. Mais je comprends tout à fait le fond du message et suis d'accord.

      À vrai dire, il y a un petit quelque chose qui m'embête vraiment :

      error = begin
         Redis::CommandError
       rescue NameError
         RuntimeError # Dirty dirty hack for redis gem before 3.0
       end

      Il s'agit de l'erreur que l'on doit matcher dans le rescue dont on parle plus haut. Catcher une RuntimeError me déplait au plus haut point, parce que c'est une erreur qui peut arriver de n'importe quoi. Ce qu'il faudrait c'est upgrader la gem redis à au moins 3.0.0, qui introduit Redis::CommandError et qui me plaît largement plus, parce que c'est exactement ce que l'on veut.

      Ou alors enlever carrément toute la partie script et la remettre le jour où on aura une version plus récente de Redis ?

      Sinon, c'est sympa d'avoir proposé un patch

      Ça ne paiera pas la bande passante dont j'ai abusé, mais ça me fait plaisir =]

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.