Rövid feed-történelem
Eleinte volt a sima RSS és Atom formátum. Végre valami gépileg értelmezhetőt kapott a programod és nem html-ből vagy valami hasonló dzsuvából kellett kibogarászni a tartalmat. Egész kis műfaj épült az RSS streamek rendszeres ellenőrzésére és megjelenítésére. Többet nem kellett a felhasználónak hetente végiglátogatnia a kedvenc blogjait, ott volt a kedvenc RSS olvasójában minden, mindig. Mikor volt az utoljára, hogy elkezdted begépelni a firefoxnak, hogy "iwillworkforfood.blogspot.com"? Soha? Sebaj, nincs harag :-)
Olyan mainstream szoftverek támogatták ezt, mint a Microsoft Outlook.
Az RSS és Atom egyetlen apró hátulütője persze az, hogy időnként rá kell nézni, és ilyenkor le kell tölteni az egészet akkor is ha semmi új nincsen benne már egy éve. A másik apró gebasz az, hogy a friss tartalom csak egy újabb poll után kerül a felhasználóhoz. A harmadik pedig az, hogy amikor többtízezren olvasnak egy fontosabb "stream"-et, akkor az jelentős extra terhelést és forgalmat jelent a weboldalnak. Ez olyan, mintha a munkahelyeden nem csak a főnököd kérdezné, hogy "mikor leszel már kész az atomreaktorvezérlő szoftverrel", hanem mindenki akinek eszébe jut. Persze a számítógépek kicsit jobban kezelik a megszakításokat, mint az emberek.
Ezek persze nem túlélhetetlen esetek, párszáz olvasónál még mindig inkáb hagynánk had pollozzon mindenki, mint hogy törődjünk ezzel az apró problémával, extrakiadást nem jelentene, és valjuk be teljesen jó az is, ha a jövő héten amikor éppen akad időd (egy fordítás alkalmából például) elolvasod ezt a bejegyzést.
Azonban a kiszolgálónknak, a blogger.com-nak pármillió ilyen blogot kell kiszolgálnia. Így nekik már komoly terhelést jelent az, hogy örökké kérdezgetik az RSS csatornákat, és nem csak akkor, amikor a felhasználónak eszébe jut, hanem amikor az RSS olvasójának eszébe jut. Olyan oldalak, mint a google news, és társai kifejezetten szeretnék a híreket a lehető leghamarabb megkapni, azaz lehetőleg poll nélkül.
Alighanem sóhajtoztak a szolgáltatások mögött álló programozók, hogy milyen szép is lenne, ha nem kellene pollozni -mert az az összes fenti gebasszal rendelkezik- hanem egyszerűen csak elküldené neked valaki a friss tartalmat. Két megoldás született az álomból:
- a cloud - ilyen támogatását én még nem láttam
- a google pubsubhubbub specifikációja - ez annál inkáb széles támogatottságot élvez
- a blogger.com nyilván az elsők között, tekintve hogy google kézben van
- hamar megjelent a támogatás a wordpress-ben és a nagy wordpress.com is bekapcsolta úgy 7.5 millió náluk hostolt blogra
- a nagy nemzetköziek mellett had említsem meg, hogy a magyar blog.hu is támogatja
- A "long tail" blogok mellett nagy halak feedjeiben is megjelent: CNN, BBC, és pár egyéb nagyobb
No, ennyit a történetről, jöhetnek a...
Technikai részletek
Nézzük hát, a specifikáció maga nem valami bolonyult. A pubsubhubbub 3 szereplős játék:
- a publisher - aki az RSS vagy Atom feedet kiszolgálja
- subscriber - aki szeretné megkapni a friss tartalmat
- hub - aki a kettő között áll. Ő leginkáb olyan mint az újságosfiú.
Elösször is, az RSS-t vagy Atom-ot publikáló weboldalnak tudtára kell adnia valahogy a klienseivel, hogy őt nem csak poll-ozni lehet, hanem ő támogat ennél okosabb megoldást is. Ez úgy történik, hogy egy atom linket kell betenni a kimenetbe, ezt megnézheted például itt akár ennek a blognak az atom feedjében is:
<link href="http://pubsubhubbub.appspot.com/" rel="hub">
Innen tudhatja a kliens, hogy melyik hub-nál kell szólnia, hogy őt érdekelné.
A publisher ezen kívül, amikor új tartalmat tesz a feed-be, szól is a hub-nak: nesze fiam, szólj mindenkinek! Ennyit kell tudnia a publishernek.
Nézzük, a subscribernek most már tudhatja a feed-ből, hogy nem kell örökké a publisher-hez ellátogatnia, hanem a publisher újságárús srácai fogják megkeresni. Neki ehhez annyit kell tennie, hogy megadja neki a címét. A kézbesítés, akárcsak a poll és a publish, http protokolon keresztül történik.
A felíratkozásra azért tettek egy kis hurkot, ugyanis ha a szerveredet felíratnám néhánymillió hiperaktív RSS csatornára, a google app engine böszme nagy szerverfarmja verné halálra a géped, illetőleg termelne neked szép nagy számlát a forgalommal. Ez pedig kimeríti a "más farkával történő csalánverés" tényállását, így mindkét fél érdekelt abban, hogy egy harmadik ilyet ne csináljon. Ebből a célból a hub visszakérdez a megadott címre, hogy tényleg innen jött-e a kérés. Miután a kérés megerősítést kap, a felíratkozás kész.
A publish nagyon nagyon egyszerű: http POST requestet kapsz a megadott címre, aminek request body-ja a friss tartalom.
Mennyire gyors? Nem nehéz kipróbálni, egy blogger.com blog kell hozzá és egy tetszőleges publikus webcím. dyndns, portforwarding, ingyenhosting, akármi játszhat. Általában mire sikerül ablakot váltanom, már ott van benne a tartalom, amit a blogger.com-ra került. Nem nevezném realtime-nak, de a pollhoz képest cefetgyors.
A fejlesztők álma az volt, hogy ez az egész elosztott lesz, azaz soksok hub lesz és mint a postahivatalok között áramlik majd a sok sok update. Hááát... ez nem lett egészen így. Természetesen csinálhatsz saját hub-ot, és a wordpress blogjai valóban tartalmaznak egy beépített hubot, ez nekem úgy tűnik a ritka kivételek közé tartozik inkáb, mint a meghatázozó szabály lenne. A pubsubhubbub-ot támogató feed-ed legnagyobb része a google hub-jára mutat. Azaz bár van lehetőség arra, hogy ez máshogy legyen, mégiscsak egy nagy hal viszi az egészet. Ha valamiért elakad egy pár órára a google rendszere (ilyen pedig minden cloud rendszerrel történt eddig), akkor még úgy se fog muzsikálni a rendszer, mint pollozással. Ezt azért szerintem érdemes belekalkulálni.
Egy kicsi extra: subhub
Majdnem elérkezett a boldogság, mert nem kell fölöslegesen böszme nagy sávszélességet vásárolni, időnként végignyalni a fél internetet, satöbbi. Amikor jön valami anyag, akkor megkapod, ezzel végülis egyszerűbb lehet a rss-feldolgozás menete.
Viszont arra gondoltam, mennyire természetesebb lenne, ha valamilyen csatornán keresztül érkeznének az RSS updatek, nekem talán egy JMS csatorna tűnik a legegyszerűbbnek. A feldolgozásról eldönthetem, hogy egymás után vagy párhuzamosan. A feldolgozást nem terheli agyon egy hirtelen forgalomhullám reggel, amikor mindenki tweet-el és updatel ésatöbbiésatöbbi. Ezzel el is tudom különíteni az feldolgozástól a pubsubhubbub-specifikus kódot, és a feldolgozás csak szin tiszta RSS/Atom xml-eket kap. Ezt az egy komponenst dobtam fel egy kívülről elérhető szerverre, a feldolgozás egy JMS queue-n keresztül tartja vele a kapcsolatot. A feldogozást akár tehetjük saját meglévő farmunkra is, ott olcsóbb a tárhely és a CPU idő is. Söt a felhőben szerintem elcseszett drága általában véve.
Ezt majd egyszer papírsárkány design pattern néven fogom szabadalmaztatni és abból leszek csilliárdos.
Hát ennyi tényleg. Boldog Szent Vencel napot :-)
