Értesítő szolgáltatás

Az Internet hőskorában a fogalom még egy, kisebb hálózatok összekapcsolásából létrejött világ méretű hálózatot jelentett. Manapság az emberek többsége már úgy gondolja, hogy az Internet nem más, mint maga a web. Ennek egyszerű a magyarázata: A HTTP protokoll és az Internet böngésző programok diadalmenete úthenger módjára tipor el minden egyéb Internetes szolgáltatást.

A korai években a felhasználás módjától függően különböző, az adott célra kifejlesztett szolgáltatásokat vettünk igénybe. Ha információra voltunk kíváncsiak, akkor a böngészővel a weben kerestük azt, ha fájlokat akartunk letölteni, akkor egy FTP szervert használtunk, ha beszélgetni akartunk egymással, akkor ott volt az IRC, elekronikus üzeneteket pedig az e-mail kliensünkből küldtünk pl. POP3 protokollon. Még régebben ott volt a Usenet (az NNTP protokollal), amin az emberek híreket olvashattak vagy beszélgethettek. Manapság már sokan már kizárólag webről töltenek le, weben chatelnek, GMail-en olvasnak leveleket, weben értesülnek a hírekről. Mi ezzel a baj? Az, hogy a webet nem erre találták ki.

Az értesítés problémája

Azzal, hogy az interaktív szolgáltatásaink a webre költöztek, azok sok előnye mellett új problémák is megjelentek. Az egyik ilyen probélma az, hogy a weboldalak nem tudnak információt eljuttatni a felhasználóknak, amikor az nem böngészi épp az adott oldalt. Így ha valaki ír chaten, vagy pl. megjelenik egy új hír, akkor bizony nincs lehetőség értesíteni erről a felhasználót.

Ez persze már másoknak is szemet szúrt, de a modern trendeknek megfelelően a megoldás nem más, mint egy gyorsan, a már meglévő elemekből összetákolt új “rendszer”, amit ma RSS néven ismerünk. Ennek lényege annyi, hogy fogtak egy XML adatstruktúrát, ami tartalmazza a felhasználóhoz eljuttatandó új információkat, majd azt mondták, hogy az RSS olvasó (gyakran nem is külön program, hanem maga a webböngésző, extrémebb esetben tudathasadásos módon pl. Google Reader, ami maga is egy weboldal) periodikusan töltse le azt a már ismert HTTP protokollon, hasonlítsa össze a korábban letöltött adatokkal, és mindenki boldog is lesz.

Azonban mindenki tudja, hogy a periodikus ellenőrzés nem egy jó módszer, mert előfordulhat, hogy kimaradnak adatok (pl. két ellenőrzés közben hozzáadnak, majd törlik is azt), felesleges adatforgalmat és szerver terhelést generál, valamint rossz esetben az RSS olvasó frissítési idejével késleltetve érkezik meg az információ a felhasználóhoz.

Innen jött az ötlet, hogy az e-mailben küldjük el ki az értesítőt az üzenetről, vagy változásról. Az e-mail azonnali, létezik Push-os verziója (ahol tehát nem kell ellenőrizgetni a postafiók tartalmát, hanem a rendszer kézbesíti az új üzeneteket, amint azok megérkeznek). Könnyű azonban elveszni a webes szolgáltatások e-mail értesítőjében: fórum hozzászólások, flickr kommentek, hírlevelek, új üzenetek, ismerős bejelölések, kedvelt (magyarul lájkolt) bejegyzések, új követők Twitteren, stb. Mindez úgy gondolom olyan információ, ami nem az ember-ember kommunikációra kitalált e-mail üzenetek ideális felhasználása. A legtöbben ezeket az értesítőket eleve ki is kapcsolják, mert bár az információ maga érdekes lenne számukra, de az e-mail áradat maga már zajként csapódik le az inboxukban.

Az ötlet

Ahogy korábban léteztek hírolvasók, létre lehetne hozni egy globális értesítő szolgáltatást egy saját protokollal, saját kliensekkel, ami sokkal hatékonyabban láthatná el ezt a feladatot. Az ilyen információk alapvetően szerintem másodlagosnak tekinthetőek, abban az értelemben, hogy bár hasznosak, tudásuk nélkül ugyanúgy el tudjuk végezni napi feladatainkat. Nem maradunk ki semmiből, ha egy-egy értesítőt nem nyom a képünkbe a rendszer. Az ilyen információk fogyasztására a legalkalmasabb egy olyan rendszer, ami folyamatsoan, de csak akkor kézbesíti az adatokat, ha a felhasználó elérhető, pl. fut az erre szolgáló kliense.

Elképzelésem szerint a különböző webes alkalmazások feliratkozhatnának erre a szolgáltatásra. Ehhez egy bizonyos mennyiségű információt mindenképpen szolgáltatnia kéne a feliratkozó tartalom szolgáltatóknak magukról (pl. weboldal címe, neve, esetleg kategória, ikon, stb.). Ezáltal a kliensek nem ömlesztve, hanem kategória vagy weboldal szerint csoportosítva jeleníthetnék meg az üzeneteket.

További előnyök

Természetesen itt még csak a káosz renddé varázslásának alapjait említettem meg. Elképzelhető egy olyan protokoll, amelyben megadható az üzenet típusa (pl. bejelölés, lájkolás, követés, hír), ami alapján a kliensek tovább tudnák szűrni a tartalmakat. A tartalom szolgáltatók közölhetnének egy listát azon értesítés típusokról, amiket támogatnak, URL-ekkel együtt, amiket a kliensek könnyedén felajánlhatnának a felhasználóknak. Így nem kéne minden weboldalon külön megkeresni a hírlevelek, értesítések be- és kikapcsolásának módját, hanem elég lenne (valahogy az RSS-hez hasonlóan) magára a weboldalra feliratkozni, és egyből az ismerős felületen érnénk el az adott oldal szolgáltatásait.

Az e-mailhez képest hatalmas előny lehetne az, ha a protokoll lehetővé tenné értesítések visszavonását. Képzeljük el az alábbi szituációt! Facebookon kiírtál valamit az üzenőfaladra, a barátaid pedig válaszolnak rá. Erről mind-mind jön az e-mail, hiszen beállítottad ezt. Azonban felesleges minden egyes üzenetről külön e-mailt kapni, bőven elég számodra az az információ, hogy meg kell nézned az adott post oldalát, ahol úgyis látni fogsz minden reakciót. Egy értesítő szolgáltatás bevezetésével a kliensek csoportosíthatnák az ilyen üzeneteket. Miközben rákattintottál az e-mailre, és olvasod a hozzászólásokat, újabbak érkeznek. Ezeket egyből látod a Facebook felületén, reagálsz is rájuk. Az e-mail értesítők azonban továbbra rendületlenül megérkeznek ezekről is. Felesleges információ, de nincs lehetőség kiküszöbölésére, hiszen az e-mail kiküldése után derül csak ki, hogy te valószínűleg már nem vagy kíváncsi rá. Ilyen esetekben a tartalomszolgáltatók visszavonhatnák az adott üzeneteket, ezzel nem zavarva téged feleslegesen.

Gondoljunk bele, lehetne egyes értesítéseknek elévülési ideje. Hiszen kit érdekel három nap múlva, hogy ismerőseink melyik kocsmába jelentkeztek be éppen.

További ötlet, hogy a különböző operációs rendszerek jelzőrendszere egyszerűen beköthető lenne a szolgáltatásba. Ha pl. egy program Growl üzenetet küldene vagy egy iOS esemény egy notify ablakot jelenítene meg, akkor azt egyből elküldhetné az értesítő rendszerbe, ami pedig az éppen használt kliensbe továbbítaná azt.

Összefoglaló

Egy értesítő szolgáltatás megszüntetné azt a kellemetlen problémát, hogy az éppen meg nem nyitott weboldalak nem tudnak értesítéseket küldeni a felhasználóknak. A rendszer használói csak akkor jutnának ezen információkhoz, amikor tényleg szükségük van rá, akkor viszont azonnal. A jelenlegi rendszerek hiányosságait (nem visszavonhatóak az értesítések; az üzenetek zajként jelennek meg a nem erre kitalált szolgáltatásokban; felesleges sávszélesség és szerver kihasználtság) ki lehetne küszöbölni. Az értesítések egy egyszerűbb, egységesen használható felületen jelennének meg, amit mindenki saját igényeihez mérten alakíthatna ki (a neki megfelelő kliens program kiválasztásával). Az átmeneti időszakban erre szolgáló webes alkalmazások (pl. a Google Readerhez hasonlóan) jelenthetnék a platformfüggetlen és mindenhol elérhető megoldást azok számára, akiknek nem elérhető az adott platformra készült natív kliens program.

7 hozzászólás

Submit a Comment
  • Aadaam

    A jo hir az,hogy van 3 ietf szabvany is a temaban, a rossz hir az, hogy egyik se mukodik.

    (Ezek kozul a legismertebb az XMPP PubSub, ill. a SIP kornyeken levo dolgok, az IMS rendszer sajatos jatekai)

    Az elso dolog,amit meg kell ertenunk, hogy ertesitest kuldeni architekturalisan viszonylag draga. Az e-mail nem annyira az, de ha jobban megnezzuk az e-mailt, akkor az ket reszbol all:
    – A kuldo protokollbol
    – Az olvaso protokollbol

    Tulajdonkeppen az e-mail is olyan mint az RSS, van mindenkinek egy szemelyes listaja, amit a mailkliens szepen 10 percenkent fetchelget. Szep dolog a push email, jelenleg nem elterjedt, idogarancia ott sincs.

    Raadasul az e-mailt a rendszer nem azonnal kuldi ki, meglepoen lassu – akar tobb oras – kikuldesi kesesek is lehetnek egy facebook eseten, es ezek utan a gmail is elszorakozhat vele 10-20 percet is csendben siman.

    A gtalkrol es mas uzenetkozvetito rendszerekrol is tudjuk, hogy ami baromi draga, az a jelenlet (online, away, stb) fenntartasa.. egyszeruen a gtalket nem birja mar az optika.

    A facebook ezt ugyesen attrukkozte: nincs nyitva alapbol a buddy list ha meg nyitva van… kitalalhatod: 10 percenkent fetcheli.

    Annak a nehany geeknek aki hasznalja, megoldottak, hogy nekik kuldjon push uzenetet XMPP-n, bar a megbizhatosagara nezve a rendszer nem tud garanciat vallalni.

    Hasonlo mintak fedezhetoek fel egyebkent mas rendszerekben is: geekeknek tenyleges push, tobbieknek meg nem; esetleg opciosan kulon szerverrendszer hasznalata (pl. blackberry push e-mail), ami csak annak a parezer embernek szol, akik fenntartjak azt a rendszert; globalis meretben sokkal nehezebb kivitelezni.

    Az iranyado architektura video a google-tol itt:

  • GK

    Szerintem leragadtál a cikk felénél :)

  • Aadaam

    Epithetsz prowl-t ( http://www.prowlapp.com/ ) de ettol meg nem lesz dragabb egy ilyen infrastruktura :)

    Tulkepp neked egy generalizalt growl kene, nem?

  • GK

    Nem.

  • Pálesz

    Tulajdonképpen GK egy majdnem twitterre gondol kategorizálással és timeout-al. Ugye?

  • Pálesz

    Csak ugye, itt a twiteket az alkalmazásod toljád a te saját fiókodba.

  • GK

    Végülis hasonlít kicsit, igen. :)

Submit a CommentPlease be polite. We appreciate that.

Your Comment