RSS: push vs. pull

Maanvis linkt naar een aantal zaken die ik zelf ook al had gelezen, maar waar ik eigenlijk niet zoveel over wist te zeggen. Immers: RSS slurpen kost bandbreedte. Ja, klopt. Lastig. En toen?

Hij noemt als oplossing, of denkwijze die tot een oplossing moet leiden, dat het concept waarmee RSS werkt, de boosdoener is. En dat is ook zo natuurlijk. Je (lees: jouw aggregator) moet elke keer zelf contact opnemen met de server om te kijken of er nieuwe items zijn. Zijn die er niet, dan heb je bandbreedte verspild aan de request. En aangezien een aggregator dit vaker doet dan jijzelf als mens, kan dat best oplopen.

De server zou dan ook naar de client toe moeten komen met een aanbod: "hey, ik heb nieuwe dingetjes, hebbuh?". Op deze manier kost het alleen nuttig gebruikte bandbreedte. Het is alleen wat lastiger, en ik vroeg me af of Maanvis daar al ideeën over heeft: moet de server dan gaan bijhouden welke clients items willen ontvangen? En hoe? RSS is nu een "zo, die feed staat, geen omkijken meer naar"-medium. Clients komen zelf zo af en toe 's kijken, en klaar ben je. De verantwoordelijkheid bij de server plaatsen geeft een publisher veel meer verantwoordelijkheid, meer werk te doen en dat kan, als tegenstelling van het gemak van RSS nu, ervoor zorgen dat websites 'dan maar geen feed' nemen.

Het is een leuk idee, de methode omdraaien, maar hoe wil je dat bewerkstelligen?

Ping. Vlak voordat ik op submit druk bedenk ik me iets. Stel dat een feed een element met daarin de update-frequentie zou hebben, en dat aggregators die gebruiken om de ophaalmomenten op af te stemmen? Dat kost moeite voor de publisher, want de frequentie moet berekend (en onderhouden) worden. Goed punt. Misschien kan een aggregator dat dan zelf doen? Zelf een frequentie berekenen en daar het schema op aanpassen? Zomaar even een los ideetje...