Gaat RSS ten onder aan eigen succes?
Doordat RSS feeds steeds bekender wordt bij de gewone websurfer en de media, begint het verwachte bandbreedte-probleem een realiteit te worden. Hoe groot is het probleem en wat is de oplossing?
Statistieken van websites als Boing Boing laten zien dat er een terechte zorg is over de bandbreedte die feeds gebruiken.
Mogelijke oplossingen voor dit probleem zijn programma?s als RSScache (feed caching proxy) en KnowNow (even-driven syndication).
Bron:
Slashdot: Is RSS Doomed by Popularity?
Via:
Marco Derksen
Partner bij Upstream
Oprichter/partner Upstream, Marketingfacts, Arnhem Direct, SportNext, TravelNext, RvT VPRO, Bestuur Luxor Live, social business, onderwijs, fotografie en vader!
P2P lijkt mij de oplossing…
Het wordt tijd dat RSS-readers leren omgaan met compressie-algoritmes. Alle benodigde technieken bestaan al jaren. Halen ze geen rss.xml binnen, maar een rss.zip. Scheelt al snel 70-90% in grootte. Koppel dat aan de caching-methode zoals RSScache die oppert, en het probleem is al goeddeels opgelost.
De oplossing is redelijk simpel. Je geeft iedereen een id in de feed mee. Vervolgens check je op de server of er nieuwe artikelen zijn since de laatste upload. Indien ja geef je alleen de nieuwe content. Indien nee geef je geen content terug.
Dit voorkomt veel onnodig gebruik van bandbreedte.
U begint met de vraag: Gaat RSS ten onder aan eigen succes? Dat problemen kunnen ontstaan ben ik met u eens, maar u laat wel een aantal vragen onbeantwoord:
Hoeveel individuele lezers moeten (vrijwel) gelijktijdig gebruik maken van 1 RSS-stream om problemen te veroorzaken (bij een gemiddelde bandbreedte)?
Lost het probleem (deels) zichzelf niet op doordat er niet alleen aan de vraagkant ontwikkelingen zijn, maar ook aan de aanbodkant?
Zijn er al voorbeelden op de Nederlandse RSS-markt bekend, die problemen hebben ondervonden met hun bandbreedte?
Het HTTP protocol heeft 2 headertags die uitstekend voorzien in het bandbreedte probleem.
De Last-modified en de ETag. De nieuwsbod van alhetnieuws gebruikt deze twee tags om te bepalen of een feed nieuwe content bevat of niet, immers met meer dan 200 feeds elke 15 minuten controleren zou de bot onnodig veel bandbreedte verbruiken.
Het idee is simpel: Sla beide tags op (in een database) en vergelijk deze wanneer je de feed opnieuw download. Zijn de waarden hetzelfde, dan kan na het inlezen van de header (circa 100 bytes) de verbinding direct verbroken worden.
In sommige gevallen worden feeds dynamisch gegenereerd op het moment van opvragen. Dit is de slechtste manier van serveren; bij elke ‘feedview’ moet de server opnieuw aan het werk om de feed te genereren, door de dynamische content wordt het door een browser of bot niet gecached en de server geeft bovenstaande twee headers niet mee.
Het is veel beter om een statische file alleen maar te updaten, wanneer er een nieuw item wordt toegevoegd. De webserver zorgt dan wel voor de juiste header.
@vincent
Bij statische files ga je uit van een paradigma dat iedereen dezelfde content wil zien. Als ik een auto zoek bij autotrader ben ik alleen geinteresseerd in een specifiek merk, jaartal, prijs. Bij amazon geldt hetzelfde.
Statische files zijn leuk maar een oud paradigma.
@paul
Het overgrote deel van alle feeds op internet geven slechts één of een paar categorieën weer. Weblogs hebben hoogstens twee verschillende feeds (artikelen / comments). Nieuwssites enkele (nieuws / sport / vrije tijd / etc).
Al deze files kunnen gemakkelijk statisch zijn en alleen maar (automatisch) ge-update worden als er iets dient te veranderen aan de feed.
Met een serverside script kun je óók aan de echte dynamische feeds (op basis van voorkeuren) de juiste headers mee geven, zodat aggregators kunnen cachen.
Kunnen (sommige) feedreaders overweg met cookies? Ik zou dat liever gebruiken dan elke gebruiker een uniek id om alleen de nieuwe berichten te tonen.
Ik zou ook de feedreader makers vragen om tenminste compressie te ondersteunen (gzip) want dit scheelt vaak 80% en wordt door sites/script talen zeer goed ondersteund.
In mijn logfiles zie ik dat MagpieRSS/YahooFeedSeeker HTTP1.0 gebruiken, maar dat Bloglines/FeedDemon/Feedreader/Feedster/RssReader/SharpReader wel HTTP1.1 gebuiken dus eigenlijk gzip zouden moeten ondersteunen. Helaas maken ze daar geen gebruik van!
@vincent. natuurlijk is het zo dat nu veel sites maar een feed geven omdat de tools die zij gebruiken dat alleen ondersteunt. Als je echter weer veel feeds hebt gaat het voordeel van webfeeds weer voor een groot deel verloren daar er vaak voor de gebruiker niet relevante informatie wordt doorgegeven.
Een ander voordeel van id is statestieken. Je kunt direct zien hoeveel unieke gebruikers er zijn en waarop zij klikken. Als je nog een stap verder gaat kun je de feed daarop aanpassen. Of ga ik nu te ver…:-)
@Marco
Bedankt voor het snelle antwoord.
Gerelateerde artikelen
Marketingfacts. Elke dag vers. Mis niks!
Marketingfacts. Elke dag vers. Mis niks!