URL: https://linuxfr.org/users/graou/journaux/gaspillage-et-protocoles-num%C3%A9ro-1-rss-atom-cie Title: Gaspillage et protocoles - numéro 1 - RSS, Atom & cie. Authors: renaud Date: 2005年01月03日T16:02:21+01:00 Tags: Score: 0 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 ?

AltStyle によって変換されたページ (->オリジナル) /