Journal Gaspillage et protocoles - numéro 1 - RSS, Atom & cie.

Posté par  .
Étiquettes : aucune
0
3
jan.
2005
Une chose que je constate depuis fort longtemps, et qui m'interpelle est la mauvaise utilisation des protocoles et standards/formats qui, malheureusement, deviennent souvent des habitudes, puis des 'comportements par défaut'. À qui la faute ? Aux développeurs je pense, qui, sous prétexte de simplicité contournent les protocoles, pour souvent un fort gaspillage en ressources : CPU et/ou BP. M'est avis que les avantages obtenus en procédant de cette façon sont récupérables en travaillant plus sur les logiciels d'interfaces...

Voilà donc le premier d'une courte série de journaux sur des 'détournements' de protocoles/formats.

La syndication de contenu est, à mon sens, la "technologie" phare de l'année 2004. La révolution des weblog l'a fait devenir de plus en plus populaire et elle a été adoptée par tous les acteurs ayant une utilité dans la syndication : bref, c'est un carton !

La syndication désigne le fait de réutiliser une source d'information afin de partager du contenu. Les objectifs initiaux de Netscape étaient clairs et simples : permettre à leurs partenaires d'apporter eux-même du contenu sur le portail Netscape. C'est à dire du server to server. Ensuite, UserLand est reparti des travaux de Netscape pour ses outils de weblog.

Le problème, je pense, est apparu avec l'arrivé des aggrégateurs ou newsreaders. Même si RSS s'est sensiblement amélioré depuis, et que Atom a intégré ces améliorations : gestion des dates, etc, je pense qu'il n'est toujours pas adapté aux utilisateurs.
En effet, on a actuellement sur les flux des milliers de clients qui téléchargent le flux des dizaines de fois par jours : le comportement par défaut de mon lecteur est réglé sur un rafraîchissement toutes les 5 minutes, soit 120 requêtes pour 10h d'activité et par flux !

Vous imaginez sans doute le gâchis. Sur la cinquantaine (je ne suis pas un addict, loin de là) de flux auxquels je suis inscrits, 90% ne sont même pas mis à jour quotidiennement. Je pourrais alors simplement configurer ces flux pour qu'ils soient individuellement rafraîchit moins souvent, mais j'aime être au courant __tout de suite__ des mises à jours : c'est normal, je suis un utilisateur lambda.
À cela, on peut aussi ajouter le fait qu'aujourd'hui la plupart des outils de weblog publient du RDF encapsulant de l'HTML pour le contenu, ce qui, si c'est très pratique et très agréable à lire, rend le fichier un peu plus lourd. De plus, RSS ayant aboli la limite des 15 items par flux, et Atom aussi...

Le problème est donc clairement un gaspillage incroyable de ressources, essentiellement réseau.

En terme de solutions, la plus évidente me semble être de séparer le champ de dernière modification du reste. Pour ce faire, on peut imaginer facilement un système de SOA, comme pour le DNS ; par exemple, avec un format XML simple décrivant l'adresse de la ressource de contenu à la manière de la balise LINK d'HTML. Cette solution conserve la simplicité technique d'RDF et la possibilité de tout gérer sans middleware.
On peut aussi imaginer une technique plus souple en terme de communication, mais plus lourde coté serveur avec un vrai service web et WDDX.

D'un point de vue plus théorique, et pour plus d'efficacité, on pourrait imaginer un système qui renverserai le problème. En effet, on est ici dans un cadre 1 to any où un contenu périodique s'adresse à beaucoup de monde. Dans le genre, il existe déjà les mailing-list, et c'est peut-être par là qu'il faille chercher la solution.
Imaginons un futur en IPv6, un utilisateur pourrait signaler au serveur qu'il est disponible, enregistrer son site dans un groupe et tout simplement attendre que le serveur envoie un multicast (UDP ?) pour signaler une mise à jour à chaque nouveau contenu. Je ne sais pas vraiment si c'est possible, je ne suis pas du tout au fait d'IPv6, mais s'il est en plus possible de récupérer au niveau logiciel les informations sur la durée de vie de l'adresse, on peut croiser cette information avec le reste pour minimiser les transferts inutiles.

Bref, tout ça me semble fortement perfectible. Avez vous des idées de solutions ? Voyez vous d'autres problèmes dans les versions actuelles ? Ai-je présenté des erreurs ?

  • # En-têtes HTTP

    Posté par  . Évalué à 10.

    Ce n'est quand même pas bien dur d'ajouter les en-têtes HTTP qui vont bien dans les requêtes pour indiquer la date du dernier téléchargement et de renvoyer un 304 lorsqu'il n'y a pas eu de modifs... déjà, qu'on commence par bien gérer ça, et ensuite on cherchera de nouvelles solutions qui n'existent pas encore.

    • [^] # Re: En-têtes HTTP

      Posté par  . Évalué à 1.

      Oh oui !
      Misère de misère, je n'avais pas pensé à ça, comme quoi, chercher midi à quatorze heure...
      Une preuve de plus que le problème se situe au niveau du développement/logiciel : aucun des logiciels que j'avais testé n'utilisait cette méthode (les flux étaient tous intégralement téléchargés).

      Je voulais aussi évoquer le problème que posait le RSS vis à vis des statistiques et qui était résolu par la pseudo-solution que j'ai mentionné plus haut.

    • [^] # Re: En-têtes HTTP

      Posté par  (site web personnel) . Évalué à 4.

      La plupart des lecteurs RSS/ATOM utilisent déjà ça. Je vois tout plein de 304 dans mes logs sur les flux de mon blog.
      Le vilain petit canard dans l'histoire, c'est Thunderbird. Lui se prends toujours une réponse 200 avec tout le contenu derrière. Esperont qu'il devienne rapidement le joli cigne qu'il pourrait être.


      Sinon je suis d'accord que les flux RSS sont souvent mal utilisé. Le truc est que maintenant tout est sur le web, donc ces flux sont très simples à mettre en place...
      Pour moi l'idéal, ça serait que tous les machins de blog et de forum type phpBB aient un système de passerelle vers des serveurs NNTP.

  • # http

    Posté par  (site web personnel, Mastodon) . Évalué à 2.

    Hello,

    pourquoi est-ce que les mécanismes d'HTTP ne pourraient pas être repris, vu que c'est le protocole qui transfert tout ça pour le moment? Je veux parler du cache, avec HEAD et 304.

    Sinon, pour compliquer, on pourrait avoir un aggrégateur qui envoie le md5 du dernier flux reçu. Le serveur ferai un md5 du flux concerné et ne renverrai le flux que si les deux hash sont différents.

    Voilà, mon demi-centime
    Bananier!

    La gelée de coings est une chose à ne pas avaler de travers.

    • [^] # Re: http

      Posté par  . Évalué à 1.

      Pour le 304, j'ai répondu plus haut, pour le md5, j'y ai pensé, c'est du même type que le SOA : avec un middleware.

    • [^] # Re: http

      Posté par  . Évalué à 2.

      Sinon, pour compliquer, on pourrait avoir un aggrégateur qui envoie le md5 du dernier flux reçu. Le serveur ferai un md5 du flux concerné et ne renverrai le flux que si les deux hash sont différents.


      on pourrait aussi affecter un ID (de type GUID) à chaque élément du flux, et le stocker comme attribut. Ainsi le client peut envoyer l'ID du dernier élément reçu, que le serveur compare avec les ID des éléments disponibles.

    • [^] # Re: http

      Posté par  (site web personnel) . Évalué à 5.

      ce md5 en HTTP ça s'appelle "ETag", et ça existe déjà (bon, ce n'est pas un md5, c'est simplement un identifiant donné par el serveur, mais ça marche).

      D'ailleurs, hum, HTTP définit aussi un content-md5 (mais qui ne sert pas au cache là par contre)

      HTTP sait même repérer quel a été le document récupéré la dernière fois par un client donné et ne lui envoyer que les mises à jour. HTTP sait tout faire, le problème n'est pas là, il est dans les implémentations

  • # HTTP

    Posté par  . Évalué à 3.

    HTTP prévois de demander si une ressource a été mise à jour avec la methode HEAD qui n'envois que l'entete HTTP relative à une ressource et en particulier la directive : "Last-Modified"
    Il suffit juste d'exploiter les protocoles de transport inferieurs correctement.

    Dam

  • # Jabber

    Posté par  . Évalué à 8.

    Le polling par HTTP c'est de toute facon inefficace de par sa nature meme. Avec Jabber tu as une technologie standardisee qui sait faire des PUSH pour te permettre d'etre au courant d'un changement, quand celui-ci arrive, et uniquement a ce moment la.

    pour les references, c'est par la :

    Publish-subscribe http://www.jabber.org/jeps/jep-0060.html(...)
    Transporting Atom Notifications over the Extensible Messaging and Presence Protocol (XMPP) http://www.xmpp.org/drafts/draft-saintandre-atompub-notify-01.html(...)

  • # Une discussion très intéressante à ce sujet

    Posté par  (site web personnel) . Évalué à 1.

    par ici : http://www.intertwingly.net/blog/2004/09/17/mod-speedyfeed(...)

  • # solution

    Posté par  (site web personnel) . Évalué à 2.

    > Bref, tout ça me semble fortement perfectible. Avez vous des idées
    > de solutions ?

    Une solution connue, vieille comme le monde : utiliser un proxy
    Tu utilises un proxy chez le FAI qui se charge de mutualiser les requêtes de tous les gens qui demandent une actu toutes les 5 minutes
    Puis, est ce que vraiment être prévenu toutes les demi heures est grave ? ça fait 6 fois moins de traffic tout de même.

Suivre le flux des commentaires

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