ç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=beginRedis::CommandErrorrescueNameErrorRuntimeError# Dirty dirty hack for redis gem before 3.0end
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 =]
[^] # Re: Rapide avis
Posté par rakoo (site web personnel) . En réponse à l’entrée du suivi pubsubhubbub. Évalué à 3 (+0/-0).
Merci pour le retour.
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 commandeevaln'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 =]
Judicieuse remarque, mais :
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 :
Il s'agit de l'erreur que l'on doit matcher dans le
rescuedont on parle plus haut. Catcher uneRuntimeErrorme 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 introduitRedis::CommandErroret 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 ?
Ça ne paiera pas la bande passante dont j'ai abusé, mais ça me fait plaisir =]