Soumrak vztahu čtenáře a provozovatele: Pubsubhubbub

RSS kanály zastarávají a je čas je nahradit. Obsah musí jít aktivněji blíž uživateli. To by mohl zajistit nový push model Pub/Sub. Jak funguje, co přinese čtenářům a co provozovatelům web serverů? Obsah až pod nos a jeho lepší, snazší distribuci.

Text vychází z článku Pub-Sub a WebHooks: Máme pro vás nové zprávy, který jsem napsal pro Zdroják a který pojednává o problematice z programátorského hlediska.

Současný web je poněkud pasivní médium – tedy v tom smyslu, že sám od sebe necpe uživateli žádné informace, uživatel si o ně musí říct (Pull model – „uživatel táhne data ze serveru“). Jsou ale situace, kdy by se hodil spíš aktivní Push model („Server tlačí data uživateli“) – např. u IM služeb, u nejrůznějších notifikací apod. Internet to řeší otevřenými spojeními, UDP tunely apod. Pokud ale zůstaneme ve světě WWW, nezbude nám, než Push simulovat pomocí Pull technik.

Klasickým příkladem, kdy by se hodil push model, je syndikace obsahu – tedy technika, při níž se čtenář přihlašuje k odběru novinek z určitého serveru. Syndikace obsahu a formáty jako RSS a Atom jsou jistě všem důvěrně známé, a jsou zároveň hezkou ukázkou toho, jak poněkud obrací směr toku informací a simuluje Push model („server informuje o novince“) v pull médiu, jakým je web.

S rozvojem webu a nástupem technik, označovaných někdy za Web3.0, někdy za „Sémantický web“ a ještě někdy za „prostě pokrok“, vznikají i nové postupy, s nimiž je simulace Push modelu komfortnější, a které navíc vedou k rozvolnění klasického vztahu mezi informačním zdrojem a čtenářem.

Syndikace

Začněme od Adama, či spíše od Atomu a RSS. Tyto dva formáty zná snad každý. Slouží k publikování stručného výtahu obsahu webové stránky v normované podobě, která je snadno strojově zpracovatelná. (Pro přesnost dodejme, že Atom není jen jiné RSS, ale že je to formát používaný spolu s RESTful rozhraními či XML-RPC API např. i pro publikování textů.)

Redakční systém na serveru vždy, když přibude nový text, vygeneruje i nový RSS soubor (nebo Atom, samosebou – dál budu pro jednoduchost psát o obou formátech jako o „RSS“), který obsahuje metadata k posledním deseti (pěti, dvaceti, padesáti – jak který web) článkům. Pod pojmem „metadata“ jsou míněny informace o čase vydání, titulku článku, autorovi, odkazu, unikátním ID atd., včetně stručného shrnutí, nebo dokonce i celých článků. Čtenář tedy nemusí v prohlížeči prolézat web a hledat, co se kde píše nového, stačí mu jen stáhnout krátký RSS soubor a podívat se, co jej zaujme.

V podstatě to vypadá, že RSS nepřineslo nic nového. Místo „Otevřu si ráno svých 20 oblíbených webů a přečtu si novinky“ tu máme „stáhnu si po ránu RSS ze svých dvaceti oblíbených webů“, což není na první pohled až takový progres. Takto publikované informace mají ale jednu velkou výhodu: jsou snadno strojově zpracovatelné, takže můžeme přenechat nudnou práci s obcházením webů a kontrolováním, co je kde nového, strojům. Stroje to ovšem řeší primitivně a hrubou silou – neustále se dotazují znovu a znovu serverů na to, jestli je něco nového.

Poněkud primitivní řešení přestává stačit ve chvíli, kdy exponenciálně roste počet informačních zdrojů (Web 2.0 stírá rozdíl mezi producentem a konzumentem), roste tedy i objem nových informací, s čímž přichází zároveň požadavky na jejich inteligentnější třídění a filtrování, a z druhé strany jde požadavek na to, aby informace byla doručena co nejrychleji, pokud možno „ihned“.

Classic RSS

V klasickém modelu zveřejňuje producent informace a RSS anotace, a čtenář (resp. jeho čtečka) si periodicky stahuje RSS serverů, které ho zajímají, a vybírá si ty, které chce přečíst. Tento způsob fungoval poměrně obstojně např. u blogů, kde čtenář většinou chtěl číst vše, co na daném blogu vyšlo. Ve chvíli, kdy s RSS přišly i velké deníky a webové magazíny, se stal ze čtečky další nástroj plný informací, mezi nimiž člověk hledá, co vlastně chce číst. Čtenář se brodí záplavou příspěvků, které ho nezajímají, a přitom tuší, že existuje spousta dalších informačních zdrojů, kde možná vychází taky něco zajímavého, ale on je číst nebude, protože o nich neví, a i kdyby o nich věděl, tak by z nich stejně nic neměl, protože by je nedokázal zpracovat.

Krok dobrým směrem byly oborové agregátory (např. Weblogy.cz), které se soustředí na určitý typ informací z určitých zdrojů. Člověk tak nemusí sledovat desítky kanálů a filtrovat jen to, co ho zajímá, ale tuto práci udělal někdo za něj. Nevýhodou je poměrně velká latence – některé agregátory se o článku dozví třeba až s několikahodinovým zpožděním.

Řešení výše zmíněných problémů přichází s modelem, který se nazývá Pub/Sub (též Pub-Sub, PubSub, SubPub, …) Zkratka označuje dva základní prvky celého systému, totiž vytváření informací (Publish) a jejich odebírání (Subscribe). Pub-Sub je komunikační paradigma, na němž jsou založeny některé služby (např. D-Bus), a jehož hlavním rysem je, že ruší pevné spojení mezi tím, kdo zprávu publikuje, a tím, kdo zprávu přijímá. Namísto jasně definované vazby („S1 přijímá zprávy od P1, S2 přijímá zprávy od P2 a P4, S3 od P1 a P3“) jsou zprávy rozdělené do tříd a „vypuštěny do světa“ s tím, že si je najde ten příjemce, kterého zajímá konkrétní třída zpráv.

Pokud aplikujeme Pub-Sub paradigma na výše diskutovaný příklad RSS, dostáváme systém, kde každý nový obsah (článek, aktualita, …) je zatříděn do určité kategorie či kategorií (podle typu, podle tématu, podle rozsahu, klíčových slov, …) a metainformace jsou poslány do systému, kde jsou zpracovány nezávisle na původci. Z druhé strany přistupují k systému čtenáři, kteří nejdou „sledovat Lupu, Živě a Technet“, ale místo toho chtějí odebírat např. „informace o startupech“.

Pro čtenáře má takový model zásadní výhody: Nemusí znát všechny zdroje informací, dostanou se tedy k němu i informace ze zdrojů, o nichž ani netušil, že existují, a ty informace jsou relevantní (nebo alespoň relevantnější).

Klíčovým prvkem takového systému je hub – tedy jakýsi uzel, který dokáže přijmout zprávu o nově vydaném článku, a který je schopen ji poslat dál. Funguje tak jako příjemce informace i jako producent, navíc dokáže s informací provést některé základní operace – např. odfiltrovat určité typy či určitá témata.

PubSub

Vzhledem k tomu, že producenti informací i huby jsou většinou realizovány jako internetové servery, které jsou stále dostupné, lze v takovém systému přejít na push model. U každého producenta se může klient (ať už hub nebo odběratel) zaregistrovat a požádat o zaslání zprávy v případě, že dojde k nějaké události (je vydán článek). Zpráva je doručena téměř ihned (má většinou podobu HTTP POST požadavku, který obsahuje informace o tom, do jaké třídy článek patří a kde je k nalezení) všem odběratelům, kteří jsou online. Huby zprávu zaregistrují, a pokud je pro ně zajímavá, pošlou ji opět svým klientům (odběratelům či dalším hubům).

Takováto struktura je velmi variabilní – mohou v ní vznikat centra, specializovaná na konkrétní obory, či naopak jiné huby, které agregují novinky z mnoha center. Huby v ní fungují jako filtry, agregátory nebo zesilovače. Informace o tom, že vyšel nový článek, se v takovéto síti šíří velmi rychle, v řádu sekund či minut, takže odběratel se o novém článku dozví velmi rychle. Huby umožňují budovat opravdu bohatou topologii spojení, kde nemusí probublávat „všude všechno“ – některé huby se mohou zaměřit pouze na určité události („nový obsah“), některé se mohou naopak zaměřit třeba jen na určité servery („fotogalerie“), jiné mohou agregovat výstupy předchozích a filtrovat je („nové fotografie v galeriích“).

Pub-Sub nenahrazuje RSS, ale doplňuje jej o servisní kanál, který dovoluje implementovat výše naznačenou strukturu. Není jistě překvapením, že velkým propagátorem Pub-Sub modelu je Google. Jeho Google Reader pomocí štítkování a doporučování jakoby naznačoval výše zmíněnou síť. Google dokonce navrhl a prosazuje protokol, zvaný PubSubHubbub, který především implementuje výše zmíněné postupy, tedy vztah Pub-Sub a huby pro události, do RSS a Atomu. Jeho specifikace (verze 0.3) říká, jakým způsobem do RSS doplnit informaci o tom, ke kterému hubu se lze přihlásit pro odběr informací (pomocí atributu rel=„hub“) a specifikuje, jak má probíhat přihlašování a komunikace mezi publisherem, odběratelem a hubem.

CIF16

Co přinese čtenářům a vydavatelům

Je jistě na místě otázka, jak moc změní tento model zažité představy o publikování informací. Na první pohled se zdá, že se akorát zesiluje noční můra vydavatelů, která přišla už s RSS, kdy jedním z hlavních argumentů proti bylo to, že „lidé nebudou chodit na náš web“. A když lidé nepřijdou na web, nekliknou na reklamu a nebudou započítáni ve statistikách, takže bude horší pozice při jednání s reklamní agenturou, a tedy menší zisk. (Kdosi to nazval „Netmonitor-driven byznysmodel“). Představa, že si informace jen tak někde poletují, aniž by bylo přímo zjistitelné (a ovlivnitelné), ke komu se dostávají, by přidělala těžkou hlavu mnoha marketingovým pracovníkům.

Je pravděpodobné, že se nakonec „Pub-Sub-Hub“ model šíření zpráv prosadí, i přes odpor vydavatelů a nechuť marketingových oddělení, protože výhody, které přináší, jsou neoddiskutovatelné: Rychlé a snadné šíření informací, možnost vybírat si takové, které příjemce opravdu zajímají, nebo zvýšení jejich užitné hodnoty tím, že jsou kategorizovány (a tak snáze dohledatelné např. sémantickými vyhledávači). Technika je připravená, technologie dostatečně laciná a výkonná a velcí hráči v čele s Google a Wordpressem tento model podporují – Google Reader technologii již integroval. Konec tradičního vztahu „vydavatel-odběratel“ je tudíž velmi pravděpodobný, vývoj směrem k decentralizaci a rozvolnění vztahů je předpokládatelný (i když nebude skokový), a jako v jiných případech i zde nakonec vyhraje ten, kdo nalezne účinný způsob, jak na něm vydělat, a prohraje ten, kdo bude vymýšlet, jak se ubránit.

Máte zkušenost s praktickou implementací Pubsubhubbubu? Otázku? Podělte se o ní na našem novém fóru forum.lupa.cz.

Anketa

Používáte RSS?

12 názorů Vstoupit do diskuse
poslední názor přidán 18. 4. 2010 17:00

Školení App Store optimalizace

  •  
    Jak dostat svou mobilní aplikaci mezi lidi
  • Jak na akvizici uživatelů mobilních aplikací na českém i světovém trhu
  • Jak správně spustit, propagovat, měřit a vyhodnotit svoji aplikaci v Google Play i v Apple App Store

Detailní informace o školení App Store optimalizace »