SeenThis - Agnès Maillard

en d’autres termes, il y a des ajouts, et un changement

le changement, c’est que LOGIN/follow/feed ne contient plus vos propres messages
donc, si vous utilisiez LOGIN/follow/feed pour exporter l’ensemble des messages que vous suivez + vos propres messages, il faut désormais utiliser LOGIN/all/feed à la place

Super !

Terminologie : c’est Atom ou c’est RSS ? :)

À priori, le code dit que c’est Atom. Mais dans les pages des gens on a toujours « RSS : Machin ».

Et sinon, vu que #SPIP n’a pas de vrai routeur d’URL, vous faites juste du htaccess pour l’instant ?

En effet il faudrait dire ATOM pour être correct, et en même temps le plus connu c’est RSS. Ou alors, décider d’utiliser RSS comme format.

Pour la deuxième question, c’est dans le fichier urls/seenthis.php qu’on fait le routage ; j’essaie d’enlever un max de choses du .htaccess et je crois qu’il serait bien utile qu’on bosse sur un routeur d’urls bien clean dans SPIP ; j’ai l’idée d’une liste de patterns qu’on lirait aussi bien dans un sens, pour écrire l’url d’un contexte, que dans l’autre, pour déduire le contexte d’une URL.

Et bon anniversaire @fil !
(un jeunot)

je crois qu’il serait bien utile qu’on bosse sur un routeur d’urls bien clean dans SPIP

Je ne peux qu’abonder, aussi bien pour toutes les pages « page=truc » qui n’ont pas de rapport avec un objet éditorial (les flux, calendrier, etc), que pour pouvoir faire plusieurs types de pages pour un même objet éditorial (auteurs/machin + auteurs/machin/contribs + auteurs/machin/modifier + auteurs/machin/notifications + etc).

On peut s’inspirer du routeur de Symfony, ou carrément en utiliser des morceaux, il est quand même pas mal foutu... Mais il faut savoir gérer un peu tous les cas possibles (objets et leur titre, arborescence d’objets, non-objet, paramètres à gogo, etc).

Faudrait un noyau qui sait potentiellement faire tous les décodages génériques (dans les deux sens, je suis d’accord), et ensuite tous nos actuels urls/truc.php ne seraient que des implémentations (de la config de schémas en fait, et peut-être quelques fonctions spécifiques à ce type d’URL, mais c’est même pas sûr pour les cas simples).

#seenthis_RSS

J’ai un soucis avec mon flux #seenthis. Si je l’ajoute tel quel dans mon widget sur Le Monolecte, j’ai bien la liste de tous les posts partagés ou publiés, mais leur url est juste celle de mon blog. Alors que le même flux, récupéré à partir d’un partage sur Google Reader fonctionne bien. C’est dans la colonne de droite de mon blog à mi-hauteur de page : Sur Seenthis est le flux qui vient de Google Reader (ce qui est fort emmerdant, parce que je n’ai aucune solution de rechange) et Test Seenthis direct c’est ce qui sort quand je copie directement ▻http://seenthis.net/people/monolecte/feed dans le lecteur de fil de news. Des idées ?

Flux invalide :
▻http://validator.w3.org/feed/check.cgi?url=http%3A%2F%2Fseenthis.net%2Fpeople%2Fmonolecte%2Ffeed

+ apparemment le validateur dit qu’une bonne pratique pour être compatible avec tous les lecteurs (et donc peut-être celui de ton blog), c’est d’ajouter un lien de relation « self ». Alors que là ya juste un lien sans attribut « rel ».

je vais corriger les erreurs de validation du flux, mais je ne constate pas d’erreur sur le blog d’@monolecte : ce matin la partie « test seenthis » fonctionne aussi bien que la partie « seenthis »

Ben non, si tu survoles les liens, ils pointent tous sur la racine de mon blog, pas sur les articles Seenthis... ce qui est fort embêtant, non ?

Quand je consulte ton blog, les liens SeenThis fonctionnent. Là, de suite. EDIT : arf de même, bizarrement, la première fois, je n’ai pas vu les 3 blocs de flux... j’ai du aller trop vite.

ah oui @monolecte, tu as raison… ben je donne ma langue au chat : sais pas ce qui fait merder ton « widget » (je sais d’ailleurs pas ce qu’est un widget).

Je ne sais pas non plus, c’est le seul flux qui merde dans le module de lecteur de flux intégré à Dotclear pour Gandiblog.
Je vais voir si je peux créer un flux dédié avec mon nouvel agrégateur de #RSS #yanobs

J’arrive à afficher mes posts seenthis sur mon blog avec la magie des boucles DATA de SPIP 3 :

▻http://www.weblog.eliaz.fr/spip.php?page=seenthis

Le seul truc qui me manque c’est la possibilité de récupérer les réponses à un seen. C’est possible ça ?

euh oui mais quelle est la source de ta boucle data ? le flux rss ?

oui pour l’instant, mais ça pourrait très bien être une simple boucle syndic_articles qui listerait les items d’un flux RSS généré par seenthis (qui à l’avantage de permettre de naviguer dans les archives).

#flux #atom et #syndication (j’ai galéré à le retrouver)

Yep @seenthis ou @fil :

1) Pourriez-vous remettre au propre ce seen dans un vrai article de documentation lié sur le côté ou en bas (bref trouvable facilement), parce que dès qu’on veut expliquer à des nouveaux gens comment suivre facilement, on galère à retrouver les différents flux. Or pour moi c’est vraiment le moyen le plus simple de « suivre ce qu’on suit » (je ne passe jamais par la page d’accueil), vu que ça permet de garder en mémoire et de distinguer ce qu’on a déjà lu ou pas.

2) Je n’arrive pas à comprendre dans la description ci-dessus la vraie différence entre « follow » et « all », ça sert à quoi ? Intuitivement j’aurais dit que « all » est plus complet que « follow » mais ce n’est pas ce qu’a l’air de dire la description. Et du coup je ne sais pas lequel je dois conseiller aux gens de suivre. En faisant un article de doc il faudrait expliquer plus précisément, je crois.

Ajouter une page de doc listant tous les flux Atom possibles
►https://github.com/seenthis/seenthis_squelettes/issues/181

Avoir des flux Atom de commentaires
►https://github.com/seenthis/seenthis_squelettes/issues/182

Avoir un flux Atom des tags qu’on suit uniquement (sans les gens)
►https://github.com/seenthis/seenthis_squelettes/issues/184

2) questionnement toujours le cas, « all » devrait intuitivement être plus gros que « follow » mais c’est l’inverse apparemment, pas cohérent/intuitif