2 System śledzący strony WWW

1 WWW z punktu widzenia użytkowników

W dzisiejszych czasach praktycznie każdy korzysta z Internetu. Internet jest częścią życia i otaczającej nas rzeczywistości podobnie do innych znanych wcześniej mediów, takich jak radio, telewizja i prasa. Najpopularniejszą usługą w Internecie pozostaje World Wide Web. Od momentu powstania w laboratoriach CERN w 1990 roku, WWW przechodził ciągłą ewolucję. Strony WWW z prostych dokumentów zawierających grafikę i tekst zmieniły się w twory pełne animacji, formularzy, podprogramów, interaktywnych elementów oraz dźwięku. Wymienianie możliwości, jakie stwarza WWW, mija się z celem -- w momencie ukończenia tej pracy lista byłaby już nieaktualna.

Mimo wyobraźni twórców kolejnych rozszerzeń oraz zastosowań stron internetowych, HTTP (ang. Hypertext Transfer Protocol, protokół komunikacji leżący u podstaw WWW) jest i pozostanie technologią typu pull (ang. pobierz). Oznacza to, że każde przesłanie strony HTML (czy ogólnie -- odpowiedzi) z serwera jest spowodowane wcześniejszym żądaniem (ang. request) ze strony klienta (np. przeglądarki internetowej) -- rys. 2.1. Z punktu widzenia użytkownika wygląda to tak: aby zobaczyć daną stronę, muszę wpisać jej adres w przeglądarce lub kliknąć na prowadzące do niej odwołanie. Oczywiście model ten ma swoje plusy -- to użytkownik decyduje o tym, co chce otrzymać. Od jego kliknięcia zależy, czy dana strona zostanie mu przesłana. Człowiek sam wybiera, co chce, a czego nie chce oglądać, co w dzisiejszych czasach szumu informacyjnego ma bardzo duże znaczenie.

Rysunek 2.1: Model zapytanie-odpowiedź w protokole HTTP

Bywa jednak, że model "zapytanie ze strony klienta -- odpowiedź ze strony serwera" zawodzi. Jest tak we wszelkiego typu sytuacjach, w których w znanym już człowiekowi źródle pojawia się nowa informacja. Zakładam, że człowiek jest zainteresowany w odebraniu tej informacji. Lecz w świecie WWW, żeby odebrać -- trzeba zapytać! Oczywiście skutecznym sposobem byłoby okresowe sprawdzanie, czy pojawiła się jakaś nowa treść w znanym uprzednio miejscu. Jednak takie rozwiązanie oznacza albo częste przekonywanie się, że nie ma nowych treści, albo przeciwnie -- bycie nie na bieżąco (nowy artykuł jest już od tygodnia?), zależnie od tego czy częstotliwość sprawdzania jest zbyt mała, czy zbyt duża. W praktyce jest to po prostu kłopotliwe. Nikt nie chce przecież zaprzątać sobie głowy pamiętaniem, żeby np. codziennie zaglądać do ulubionego serwisu motoryzacyjnego, a co tydzień na stronę funklubu Nissana.

Jak to zwykle w życiu bywa, potrzeba została zauważona, a rynek zareagował. Powstałe pomysły i rozwiązania tego problemu można generalnie podzielić na dwie kategorie: technologie typu push (ang. wyślij) oraz wykorzystanie poczty elektronicznej. Technologie push, będące rozwinięciem klasycznego WWW, działają w następujący sposób: użytkownik deklaruje, jakie treści w danym serwisie internetowym go interesują i od tego momentu treści te są wysyłane do niego automatycznie (niejako wpychane -- stąd nazwa, rys. 2.2). O ile standardowe wykorzystanie WWW można porównać do kupowania prasy (żeby kupić gazetę, trzeba pójść do kiosku i o nią poprosić), o tyle mechanizm wpychania jest podobny do prenumeraty lub subskrypcji. W tym kontekście użytkownika często nazywa się subskrybentem, a cały proces -- subskrypcją. Treści wysyłane do użytkownika są zapisane w formacie HTML, więc do ich odtworzenia wystarczy przeglądarka internetowa, lecz do działania całości niezbędne jest też odpowiednie oprogramowanie na serwerze oraz dodatkowe oprogramowanie u klienta.

Rysunek 2.2: Mechanizm push

Producenci zaproponowali szereg rozwiązań: protokoły przesyłania treści, oprogramowanie serwera i klienta, formaty kanałów (ang. channel -- tematycznie pogrupowane treści). Na rynku pojawiły się produkty firm Marimba (Castanet), Netscape (Netcaster), BackWeb, Tibco (TIBnet), Intermind, PointCast i innych. Firma Microsoft zaprojektowała i propaguje własny format definiowania kanałów CDF (Channel Definition Format). Początkowy entuzjazm dla technologii typu push oraz pojawianie się kolejnych produktów komercyjnych -- głównie w roku 1997 i następnych -- sugerowały, że model subskrypcji i wysyłania treści klientowi przyjmie się na dobre. Jednak tak się nie stało. Było to spowodowane głównie brakiem możliwości łatwego śledzenia odbiorców, koniecznością instalowania osobnego oprogramowania po stronie klienta, błędnymi (zwykle) szacunkami dotyczącymi liczby odbiorców. Mechanizm wysyłania treści okazał się być kosztowny z powodu drogich produktów komercyjnych oraz czasochłonnej obsługi nawet darmowych produktów klienckich. A przeważył, jak zwykle w takich sytuacjach, czysto rynkowy powód, wynikający pośrednio z pozostałych: reklamodawcy nie podchwycili tego sposobu przekazywania informacji.

Drugim sposobem na informowanie użytkownika o nowych treściach lub wręcz ich przesyłanie jest poczta elektroniczna. Ma ona szereg zalet w porównaniu z technologiami typu push opartymi na WWW. Przede wszystkim wykorzystanie istniejącego już środka komunikacji, jakim jest poczta elektroniczna, nie pociąga za sobą konieczności tworzenia i instalowania dodatkowego oprogramowania po żadnej ze stron (serwera czy klienta). Programy pocztowe są ze sobą zgodne, tzn. list elektroniczny zostanie (w przybliżeniu) tak samo odczytany przez każdy z programów. Poczta elektroniczna jest naturalnym kanałem komunikacji typu push -- to nadawca wysyła list, wpychając go niejako odbiorcy.

Rysunek 2.3: Powiadomienie przy pomocy poczty elektronicznej

Najbardziej rozpowszechniony mechanizm informowania o nowych treściach przy pomocy poczty elektronicznej jest pokazany na rys. 2.3. Najpierw użytkownik podaje swój adres poczty elektronicznej na odpowiedniej stronie interesującego go serwisu (1). Następnie, gdy nowa treść pojawia się w serwisie (powiedzmy, na stronie C), list z informacją o tym jest wysyłany do wszystkich osób, które podały swój adres poczty elektronicznej (2). Ponieważ analizuję mechanizm z punktu widzenia użytkownika, nie jest ważne, co bezpośrednio powoduje wysyłanie listów (np. czy serwis automatycznie widzi, że coś się w nim zmieniło, czy administrator własnoręcznie musi napisać i wysłać powiadomienie). List z powiadomieniem, że strona C się zmieniła, dociera do użytkownika i jeśli użytkownik zdecyduje, że chce obejrzeć tę stronę, dalej już wszystko dzieje się tak jak na rys. 2.1. Użytkownik wysyła żądanie o przesłanie strony C (3), a serwer HTTP ją przesyła (4). Oczywiście między zdarzeniem 1 (zapisanie się na listę) a 2 (wysłanie powiadomienia o zmianie) może minąć dużo czasu. Użytkownik nie musi w tym czasie myśleć o sprawdzaniu serwisu obawiając się, że przeoczy nowe treści -- po prostu czeka na powiadomienie.

2 Serwis CoNowego.pl

Mechanizm powiadomień poprzez pocztę elektroniczną opisany w poprzednim punkcie jest bardzo wygodny, lecz użytkownik nie ma wpływu na to, czy jego ulubiony serwis oferuje taką funkcjonalność. Ponadto podawanie swojego adresu poczty elektronicznej w wielu miejscach zwiększa ryzyko, że adres ten dostanie się w niepowołane ręce (tzn. do nieodpowiedniej bazy), co zaowocuje zalewem niechcianej poczty (tzw. spamu). Moim pomysłem na rozwiązanie tych problemów było stworzenie osobnego serwisu internetowego, który regularnie sprawdza interesujące użytkownika strony. Gdy zawartość którejś ze sprawdzanych stron ulegnie zmianie, serwis wysyła listy elektroniczne z powiadomieniem do użytkownika. Serwis ten nazwałem CoNowego.pl

Rysunek 2.4: Schemat działania serwisu CoNowego.pl

Schemat działania serwisu jest pokazany na rys. 2.4. Aby skorzystać z funkcjonalności serwisu, użytkownik musi podać swój adres poczty elektronicznej oraz adresy stron WWW, które go interesują (1). Od tego momentu serwis co jakiś czas (np. raz na dobę) łączy się z odpowiednim serwerem i wysyła żądanie przysłania na przykład strony C (2). Serwer HTTP przesyła do serwisu informacje o stronie C (między innymi wielkość i datę ostatniej modyfikacji) lub pełną treść strony (3). Serwis korzystając z odebranych informacji sprawdza, czy strona C się zmieniła od czasu ostatniego sprawdzenia. Operacje 2 i 3 są powtarzane automatycznie, aż okaże się, że zawartość strony uległa zmianie. Wtedy serwis wysyła do zainteresowanego użytkownika list elektroniczny z powiadomieniem o zmianie treści strony (4). Użytkownik, jeśli jest nadal zainteresowany, wysyła żądanie przesłania strony bezpośrednio do odpowiedniego serwera (5) i ją odbiera (6).

Z dotychczasowych rozważań może wynikać, że użytkownik może śledzić jedynie strony WWW zapisane w formacie HTML. Oczywiście nic nie stoi na przeszkodzie, aby serwis sprawdzał zawartość znajdującą się pod wskazanymi adresami URL, nawet jeśli będą to skrypty PHP, ASP czy Perl lub dowolne binaria (grafika, pliki w formacie ZIP itp.). Dla uproszczenia w dalszej części pracy będę jednak używał terminu strona na określenie treści dostępnych pod wskazanymi przez użytkowników adresami -- w szczególności dlatego, że głównym zastosowaniem systemu będzie sprawdzanie zmian typowych stron WWW.