\chapter{Együttműködés a web-en}

Mit tehet az internetező, ha kíváncsi, milyen újdonságok vannak kedvenc oldalain? Legáltalánosabban, végigjárja az őt érdeklő weblapokat, újdonságok után kutatva. Ugyanígy, ha egy weboldal tulajdonosa saját oldalán akar megjelentetni a témához illeszkedő weblapok híreit, cikkeit, folyamatosan az érdekesnek ítélt weblapokat kell böngésznie. Hamar felmerült az ötlet, mi lenne, ha az újdonságok, friss tartalmak automatikusan érkeznének meg.

\section{A kezdetek}

Az első próbálkozások között említést érdemel a PointCast. A PointCast vállalat 1992 óta egy olyan szoftvert készített, amely friss híreket jelenített meg a felhasználó képernyőjén, mégpedig egy képernyőkímélőben elhelyezve. A PointCast szerverei folyamatosan küldték a híreket és reklámokat; komoly médiafigyelmet is kapott a termék, amikor 1996-ban elindult. Történetesen a Windows 98-ban is integráltan jelen volt. Újdonságnak számított ez akkortájt, de a népszerűsége elég alacsony maradt, leginkább azért, mert a sávszélességigénye meghaladta az akkoriban elérhető modemes internet kapacitását, és a tartalomhoz képest túl sok reklámot jelenített meg. A felhasználók nem is mindig találták hasznosnak az információkat.

Egy másik jelentős fejlesztés Ramanathan V. Guha, indiai informatikus nevéhez fűződik: 1995 és 1997 között az Apple-nél kidolgozták a Meta Content Framework-öt (MCF), egy olyan formátumot, amely weboldalakról tárolt metaadatokat és más információkat. Amikor kiderült, hogy az Apple nem kívánja folytatni a fejlesztést, Guha átigazolt a Netscape-hez, és ott folytatta. Ekkoriban találkozott Tim Bray-jel, aki akkortájt az XML kidolgozásán fáradozott, és segítségével XML alapokra ültette át az MCF-et, amelyből később kifejlesztette az RDF-et.

A Microsoft is előrukkolt a fejlesztésével, amely friss infókat szállított a felhasználók desktopjára. Ez volt a Channel Definition Format (CDF), a célja egy weboldal tartalmának és struktúrájának leírása volt. Az elfogadottsága mérhetetlenül kicsi maradt, a lehetőségei szűkösek. Az alapja már ennek a formátumnak is XML volt (bár nem szabványos módon).

1997-ben a Netscape egy újabb technológiát mutatott be, az Aurorát, amely a még be sem fejezett RDF-en alapult. Valamivel később még ebben az évben, Dave Winer egy saját tervezésű XML-alapú formátumot publikált, a ScriptingNews-t, amelyet saját blogján kezdett el használni és ajánlani. (Dave Winerről még hallunk a későbbiekben is. Egyébként az ő blogja egyike a legkorábban megjelent blogoknak.)

\section{Push vs. pull}

Bármilyen adat, amely a felhasználót érdekli vagy a felhasználónak szól, a szervertől a kliens irányába áramlik. Amiben megkülönböztethető az ilyen kommunikáció, az a kezdeményező fél.

Ha a kezdeményező a (központi) kiszolgáló, akkor \emph{push} technológiáról beszélünk. Ez általában feltételez egy előzetes megállapodást, regisztrációt, előfizetést, amelyben a kommunikáció részleteit rögzítik, például hogy hogyan, mikor, és milyen adat küldését kezdeményezheti a kiszolgáló. Tipikusan ilyen alkalmazás például az SMTP, az azonnali üzenetküldők (instant messenger, mint például az ICQ vagy a Jabber-hálózatok) protokollja, vagy a rövidszövegesüzenet-szolgáltatás (SMS) a GSM-hálózatokon. A fenti korai szindikációs protokollok közül ide tartozik a PointCast.

Amennyiben a kommunikáció kezdeményezője az ügyfél, akkor a \emph{pull} technológa áll a kommunikáció mögött. Itt a szolgáltatástól függően szükséges lehet előzetes regisztráció, de nem minden esetben kötelező. A elektronikus levelezésben (szemben az imént említett SMTP-vel) ilyen protokoll a POP3 és az IMAP4, de ide tartozik a HTTP is (a legtöbb esetben, mivel a HTTP-nek is van push-változata). Mivel a -- PointCast kivételével -- korábban említett technológiák csak formátumok, azok a leginkább a HTTP-re támaszkodnak, vagyis ide sorolhatók.

Figyelemreméltó, hogy a push-hoz hasonló protokoll hogyan váltható ki pull technológiával. Tekintsünk egy email szolgáltatást, amelyben a levelező kiszolgálóhoz POP3-elérést biztosítanak. Ha a levelezőprogram úgy van beállítva, hogy az új leveleket az indítás után is rendszeresen (mondjuk 5 percenként) lekérdezze, akkor a felhasználó úgy tapasztalja, mintha a levelet a kiszolgáló küldené (amennyiben gyakran kap leveleket, és a levelezőprogram folyamatosan fut). Technikailag pull protokoll segítségével így push szimulálható. Hasonló módon, tervezhető olyan üzenetküldő rendszer, amelyben az üzeneteket (rövid üzenetek) a szerver tárolja, és minden kliens rendszeresen (néhány másodperces periódussal) lekérdezi a neki szóló üzeneteket. A felhasználók észre sem veszik, hogy nem a szerver küldi az üzenetet, hanem a kliensprogram kéri el.

\section{Feed és aggregátor}

Abban, hogy push vagy pull technológiát használnak, a szindikációs technikák is eltérnek. Bár, ahogy láttuk, nagy túlsúlyban vannak a potenciálisan pull-alapú szindikációs protokollok. Láthattuk, hogy a PointCast push technikája, bár felkapott lehetőség volt, a felhasználók számára nem volt kellőképp ellenőrizhető -- dönteniük kellett, hogy használják a szolgáltatást, vagy teljesen kiszállnak belőle.

A másik lehetőség sokkal vonzóbb lehet a felhasználó számára. A korai szindikációs formátumok nem voltak ugyan egyenértékűek a PointCast-tel, de valamilyen információt hordoztak a weboldalról, amelyhez tartoztak, és igény szerint voltak lekérdezhetőek. Amennyiben változó tartalommal, a változás követhető is lehet. Ez egyenes irányt mutat az RSS felé. Sőt, az RSS és az Atom pontosan ezen az elven működik.

A \emph{feed} (csatorna, hírfolyam -- sajnos nem létezik kellőképp elfogadott és elterjedt magyar változat) egy lista, amely frissített tartalomelemeket foglal magában. A feedet általában a tartalom szolgáltatója hozza nyilvánosságra (bár elképzelhető olyan szituáció, amikor nem, például screenscraper futása során). Többnyire XML-alapú dokumentum, amelyben az elemek (leggyakrabban) egy friss hír vagy egy friss naplóbejegyzés egyedi oldalára mutató linket és más metaadatot tartalmaznak. Természetesen a feedet frissíteni kell, amikor friss tartalom jelenik meg.

Egy érdekelt fél (felhasználó vagy más ágens) egy feedre virtuálisan feliratkozhat. Ez azt jelenti, hogy egy megfelelő szoftver segítségével rendszeresen lekérdezi az adott feedet, így folyamatosan hozzájut a legfrissebb információkhoz (hírekhez, linkekhez, stb.): ez a szoftver az \emph{aggregátor}. Az elnevezés arra utal, hogy egy aggregátor több feedre is feliratkozhat, így azok tartalmát összefésülheti, egységesen jelenítheti meg, vagy szűrheti is. Sőt, nem ritka, hogy egy aggregátor több feed összefésüléséből újabb feedet hoz létre, amely aztán ismét publikálható.

Ezt az architektúrát összehasonlítva egy hírlevél-szolgáltatással, megállapíthatjuk, hogy míg a hírlevél esetében meg kell adni a szolgáltatónak emailcímünket (vagyis előzetes megállapodás szükséges, ahogy egy push technológiánál -- minthogy az is, hiszen SMTP-t használnak), addig a feedek esetében semmilyen előzetes információcsere nem szükséges (leszámítva, hogy tudnunk kell a feed helyét). Az előfizetés a hírlevél esetében a szolgáltatónál történik, míg a feed esetében az aggregátorban jegyezzük be, hogy hogyan érhető el a feed. Ez HTTP esetében egy URL feljegyzését jelenti. Nem mellesleg, mivel nem osztjuk meg emailcímünket, megkímélhetjük magunkat a spamtől. Ha pedig már nem kívánunk értesülni a frissítésekről, nem kell leiratkozni: egyszerűen eltávolítjuk az URL-t az aggregátorból.

\section{Sokoldalú feed}

Bár maga a feed nem több, mint egyszerű elemek sorozata, a felhasználási lehetőségek száma meglepően magas. Valószínűleg össze sem lehetne számolni, mert az aggregátorok nagyon sokfélék lehetnek.

\subsection{Webes újdonságok}

A legegyszerűbb lehetőség a blogokon elhelyezett feedek, ezek a legújabb naplóbejegyzéseket tartalmazzák, vagy legalábbis a bejegyzés címét, a létrehozás és/vagy a módosítás dátumát, egy részletet a bejegyzés szövegéből vagy magát az egész szöveget, és egy URL-t a bejegyzés egyedi lapjára. Ezen kívül az egész oldalra vonatkozó információkat is tartalmaznak, például az oldal címét, a létrehozó nevét és emailcímét, az oldal leírását és URL-jét, nyelvét, stb. Itt emlékeztetem az olvasót, hogy legkorábban, 2001 táján a blogok voltak az első bevezetői a feedeknek. Egy másik alkalmazás a hírportáloknál jelent meg, a friss híreket hozták ebben a formában is nyilvánosságra. Azonnal belátható azonban, hogy bármilyen híreket, újdonságokat nyilvánosságra hozó weboldalon használható a technológia.

Feedet bármihez létre lehet hozni. A blogoknál például meg lehet bolondítani a képletet azzal, hogy feedet adhatunk minden bejegyzéshez kapcsolódóan a hozzászólásokhoz, vagy az összes hozzászóláshoz együttesen. Egy blogon belül adhatunk feedet az összes címkéhez, egyedileg, amelyben csak az adott címkéhez kapcsolódó friss bejegyzések szerepelnek. Sőt, újabban keresési eredményeket is el lehet érni feeden keresztül -- ennek a feldolgozására már csak megfelelő aggregátort kell találni. (Például, egy aggregátor több feedet is összefésülve, azokat a keresési paraméterrekkel elérve, több keresőmotorból származó adatot szolgáltat egy helyen.)

Mivel a feedeket az aggregátorok képesek feldolgozni, így a megjelenítésről is az aggregátorok gondoskodnak. Az aggregátor lehet egy asztali kliensprogram, ekkor általában valamilyen hírolvasásra alkalmas felülettel rendelkezik. A bejegyzett feedeket külön vagy összefésülve kezeli, és a feed egy elemének kiválasztásakor megjeleníti a feedelemben tárolt információkat vagy a mutatott URL alatt található weboldalt. Ma már több népszerű levelezőprogram is támogatja a feedeket, és a felület tökéletesen alkalmas is a megjelenítésre, ha például egy hírlevél-szolgáltatást feeddel helyettesítünk. A böngészőprogramok is (már az Internet Explorer is) támogatják a feedeket, például a Mozilla Firefox úgynevezett ,,intelligens könyvjelzők'' formájában. Létezik olyan aggregátor, amely a képernyő kis területén, széles csíkban jeleníti meg a regisztrált feedekben megjelenő híreket, összefoglalójukat vagy csak címüket futó szövegként.

Az asztali és felhasználó-oldali klienseken túl léteznek úgynevezett feedolvasó szolgáltatások, amelyek a böngészőprogramban jelennek meg, és nem igényelnek natív asztali klienst. Természetes környezetet jelent ez, hiszen a böngészőprogram azonnal adott a weboldalak megjelenítéséhez. Ilyen szolgáltatás például a Google Reader és  Bloglines. Más szolgáltatásokkal, például a Netvibes, az iGoogle, a live.com vagy a Pageflakes használatával gyakorlatilag egy személyes oldal állítható össze, amelyen megtalálható a számunkra érdekes összes olyan weboldal legfrissebb összefoglalója, amely valamilyen formában feedben szállítja a legrissebb tartalmakat. (Ezek az odalak egyébként különböző minialkalmazások elhelyezését teszik lehetővé saját oldalunkon, ezek között van a feedolvasó.) Az online feedolvasók túlnyomó többsége AJAX-ot használ az oldal kinézetéhez és a tartalom frissítéséhez.

A feedekből a webmesterek is profitálhatnak, mert oldalaikon automatikusan jelenhetnek meg eredetileg más oldalakon publikált friss hírek, így valódi webes együttműködés jön létre a két oldal között.

\begin{figure}
% \begin{wrapfigure}{r}{6cm}
\begin{center}
\includegraphics[width=\textwidth]{netvibes.eps}
\end{center}
\caption{A Netvibes feedolvasója a webböngészőben}
\label{fig:netvibes}
% \end{wrapfigure}
\end{figure}

\subsection{Speciális feedek}

A feedek nem csak weboldalak tartalmának összefoglalására és az új tartalmakról szóló értesítésekre használható; pontosabban fogalmazva, nem csak weblapok lehetnek friss tartalmak. Az RSS-ben az \verb+enclosure+ tag megjelenésével lehetővé vált multimédiás állományok feedelemekhez csatolására, és ez közvetlenül elsősorban a \emph{podcasting}, a fotófeedek és a \emph{vodcasting}, \emph{vlogging} megjelenéséhez vezetett. A podcasting azt jelenti, hogy a feedelemekben a weboldalra mutató link helyett egy zenei állományra mutató URL jelenik meg, így az a feed frissülésekor letölthető, és egy megfelelő lejátszó csatlakoztatásakor a számítógéphez, arra automatikusan áttölti az aggregátor. Ezt a módszert először iPod-oknál használták -- a neve innen származik --, és ma már számtalan alkalmazása ismert: ilyen módon terjesztenek rádióműsorokat, zenei összeállításokat, újságok interjúit vagy oktatási segédanyagokat. A vodcasting ennek a videókra értelmezett változata. A fotófeedekhez csak látogassunk el például a \url{www.flickr.com}-ra vagy a Google Picasaweb szolgáltatásának oldalára.

Érdekes jelenség, hogy újabban már BitTorrent-kliensekbe is beépítik a feedek támogatását (melyek így aggregátorrá válnak). Ezek a kliensek alapvetően nem HTTP-re építenek, de .torrent kiterjesztésű állományokat használnak egy adott file vagy file-csoport elérésének leírására. Amint azonban automatikusan férhetnek hozzá a weben keresztül a .torrent állományokhoz, ez azt jelenti, hogy az általuk címzett adatokhoz is automatikusan férhetnek hozzá. Így ebből a webes lehetőségből egy alapvetően nem webes alkalmazás is tudott profitálni.
