![[Home]](/static/yumyum.gif)
Mianem komunikacji natychmiastowej (Instant Messenging, IM) określa się całą rodzinę serwisów, pozwalających na wymianę komunikatów pomiędzy użytkownikami w czasie rzeczywistym poprzez sieć, na przykład Internet. W odróżnieniu od innych serwisów komunikacyjnych, takich jak poczta internetowa, fora czy grupy dyskusyjne, w przypadku komunikacji natychmiastowej adresat wiadomości otrzymuje ją tak szybko, jak tylko się da, dzięki czemu można prowadzić rozmowy. Oczywiście, natychmiastowe doręczenie wiadomości nie zawsze jest wykonalne – adresat może być akurat zajęty, może odejść od komputera albo nawet nie mieć komputera włączonego. W takim przypadku komunikat będzie przechowywany do momentu, gdy jego dostarczenie jest możliwe. Aby poradzić sobie z tym problemem, serwisy komunikacji natychmiastowej często oferują informacje o obecności, dzięki czemu użytkownicy wiedzą o swojej obecności, a gdy odchodzą od komputera, mogą zostawiać wiadomości – podobnie jak w automatycznej sekretarce. Komunikacja natychmiastowa jest nieco podobna do serwisów w rodzaju IRC (Internet Relay Chat) czy też popularnych czatów
– jednak tutaj największy nacisk położono na komunikację pomiędzy pojedynczymi użytkownikami.
Termin komunikat natychmiastowy
(instant message) został wymyślony przez Paula A. Linebargera i użyty w opowiadaniach science fiction które stworzył w latach sześćdziesiątych pod pseudonimem Cordwainer Smith. Komunikaty te, nadawane przez specjalne, bardzo drogie urządzenia, mogły przemierzać galaktykę z prędkością większą niż światło. Prawdopodobnie pierwszy system komunikacji natychmiastowej został wprowadzony we wczesnych latach siedemdziesiątych, jako część programu zdalnego szkolenia PLATO. Kolejny serwis komunikacji natychmiastowej został stworzony w 1987 roku przez MIT w ramach projektu Athena pod nazwą Zephyr. Jest on używany do dziś, głównie w kręgach uniwersyteckich.
Pierwszym popularnym, publicznie dostępnym tego typu serwisem jest ICQ, program stworzony przez izraelską firmę Mirabilis. Został po raz pierwszy wypuszczony na rynek w listopadzie 1996 roku. W 1998 roku firma AOL Time Warner wykupiła firmę Mirabilis, a wraz z nią także ICQ. Popularność ICQ spowodowała, że w krótkim czasie powstało wiele podobnych systemów komunikacji, każdy z nich oparty na własnym protokole. W maju 1997 roku pojawił się AIM, stworzony przez firmę AOL Time Warner. W lutym 1999 roku pojawił się chiński OICQ, który, oskarżony przez Mirabilis, zmienił później nazwę na QQ. Jest to serwis o bardzo dużej ilości użytkowników. W lipcu 1999 roku Microsoft wypuścił MSN Messenger. W tym samym czasie pojawił się także Yahoo! Messenger. W 2003 roku na rynku pojawił się Skype, stworzony przez Niklasa Zenströma i Janusa Frisa, twórców popularnego programu P2P o nazwie Kazaa. Skype bazuje głównie na komunikacji głosowej – można za jego pomocą nawet prowadzić rozmowy telefoniczne – dzwonić na prawdziwe
telefony. 19 grudnia 2002 roku, firma AOL Time Warner opatentowała w Stanach Zjednoczonych komunikację natychmiastową, jednak nie mają zamiaru wykorzystać tego patentu w najbliższym czasie. W Europie na szczęście prawo nie zezwala na taki patent. Nazwa komunikator natychmiastowy
(Instant Messenger) jest zastrzeżona przez AOL Time Warner, wraz ze skrótem IM – to dlatego program, znany dotychczas jako GAIM lub gAIM musiał zmienić nazwę na gaim lub Gaim. W Polsce rosnącą popularnością cieszą się Gadu-Gadu, Tlen oraz WP kontakt.
Praktycznie każdy z serwisów komunikacji natychmiastowej używa własnego, zamkniętego protokołu. Jeśli chcemy mieć kontakt z użytkownikami, mamy dwie drogi do wyboru – uruchomienie wielu komunikatorów na raz, lub używanie komunikatora, który potrafi obsługiwać wiele protokołów. Pierwsze z rozwiązań nie jest zbyt wygodne. Drugie także nastręcza wiele problemów. Protokoły zmieniają się i ewoluują – czasem po to, aby dodać nowe możliwości lub ulepszyć istniejące rozwiązania, czasem tylko po to, aby można było korzystać z serwisu wyłącznie z pomocą komunikatora udostępnianego przez daną firmę. Niektóre serwisy, jak na przykład Gadu-Gadu, wręcz zabraniają używania jakichkolwiek klientów innych niż ten oferowany przez nich.
Dużym problemem jest także zamknięcie protokołów. Twórcy wieloprotokołowych komunikatorów większość pracy muszą poświęcać zgadywaniu
jak dany protokół działa – najczęściej przy użyciu snifferów sieciowych lub stosując tzw. reverse-engineering. Problemem jest także komunikacja pomiędzy używającymi tego samego protokołu użytkownikami różnych sieci. Wiele firm oferuje swoje oprogramowanie do komunikacji natychmiastowej korporacjom, które mogą użyć go do stworzenia systemu komunikacji w obrębie sieci lokalnej. Jednak użytkownicy takich serwisów nie mają możliwości komunikowania się z uzytkownikami innych sieci.
Miało miejsce wiele prób stworzenia uniwersalnego standardu komunikacji natychmiastowej. SIP i SIMPLE oraz APEX, stworzone przez IETF. XMPP to część protokołu Jabber zaadaptowana przez IETF.
W roku 1998 Jeremy Miller rozpoczął pracę nad protokołem, który miał połączyć rywalizujące ze sobą komunikatory w jedną sieć. Jego rozwiązanie miało spełniać następujące założenia:
Ostatnie założenie jest bardzo istotne. Jeremy nie miał środków, aby stworzyć i zarządzać wielką farmą serwerów, niezbędna w przypadku scentralizowanej architektury.
Pierwsza publiczna wersja Jabbera, bo tak zostało nazwane to rozwiązanie, została opublikowana w maju 2000 roku. Głównym jego składnikiem był serwer, jabberd, implementujący nowy protokół, oraz pozwalający na połączenie z komponentami umożliwiającymi porozumiewanie się z innymi sieciami komunikacji natychmiastowej. Otwartość, rozszerzalność i prostota protokołu zaowocowały szybkim rozwojem społeczności Jabbera. Organizacja o nazwie Jabber Software Foundation
jest dziś głównym ośrodkiem rozwoju Jabbera. Jej działanie jest oparte o obieg dokumentów, tak zwanych JEP (Jabber Extension Proposal). Użytkownicy Jabbera mają do wyboru ponad kilkaset implementacji klienta i kilkanaście implementacji serwera. Niektóre z nich są płatne, inne darmowe oraz wolne. 4 października 2004 roku, IETF (Internet Engeneering Task Force) opublikowało oficjalne specyfikacje protokołu XMPP (Extensible Messaging and Presence Protocol), bazującego na Jabberze i kompatybilnego z nim w miarę możliwości. Wymagania postawione przez IETF wymusiły wprowadzenie szyfrowanych połączeń i zaostrzenie reguł powiadamiania o obecności, oraz ulepszenie obsługi błędów, lecz podstawowy protokół pozostaje taki sam – większość istniejących klientów i serwerów Jabbera jest kompatybilna z XMPP. Jabber jednak nie stoi w miejscu – cały czas jest rozwijany, cały czas pojawiają się nowe możliwości, jak na przykład przesyłanie plików, powiadamianie o tym, że nasz rozmówca właśnie pisze wiadomość, jeden z klientów umożliwia nawet rysowanie podczas rozmowy na specjalnej tablicy. Wszystkie te rozszerzenia są częścią Jabbera, lecz nie XMPP.
Jabber nie jest zależny od żadnego centralnego serwera, bazy użytkowników czy organizacji. Każdy może postawić swój własny serwer, bez konieczności jakiejkolwiek rejestracji, przydzielania zasobów czy innych formalności. Wszystkie serwery są równouprawnione – nie pośród nich żadnych wyróżnionych, czy o większych prawach niż inne. Nie istnieje żadna centralna lista serwerów Jabbera. Serwery nie przechowują też żadnych lokalnych list, jak ma to miejsce w niektórych rozproszonych sieciach p2p. Zamiast tego, sam identyfikator użytkownika zawiera w sobie adres serwera na którym dany użytkownik jest zarejestrowany. Podobnie jak w przypadku SMTP, jeśli któryś z serwerów otrzyma komunikat adresowany do użytkownika na innym serwerze, po prostu przekazuje ten komunikat dalej, do tego właśnie serwera. Jeśli gdzieś wystąpi błąd, to informacja o tym trafi do nadawcy tą samą drogą, tylko w przeciwnym kierunku.
Komunikacja klient-serwer i serwer-serwer odbywa się przy pomocy tych samych mechanizmów. Ze względu na założenia Jabbera, jak największa ilość pracy jest wykonywana po stronie serwera. To serwery zawiadują wymianą komunikatów i informacji o obecności, to one przechowują dane o użytkownikach, ich uprawnienia i listy kontaktów. Klient Jabbera jest dzięki temu bardzo prosty do napisania – autor może skupić się na interfejsie użytkownika, gdyż rola klienta sprowadza się praktycznie tylko do nawiązania połączenia z serwerem i prezentacji danych od niego otrzymywanych.
Oprócz klientów i serwerów Jabbera, w architekturze uwzględnione są także tak zwane transporty. Od strony użytkowników Jabbera transport wygląda i zachowuje się jak normalny serwer. Jednak komunikaty które otrzymuje i wysyła tłumaczone są w nim na inny protokół komunikacji natychmiastowej. Dzięki temu na przykład transport będący bramką Gadu-Gadu wygląda dla użytkowników Jabbera jak zwykły serwer, na którym konta mają wszyscy użytkownicy Gadu-Gadu – dzięki czemu w praktyce Gadu-Gadu staje się częścią sieci Jabbera. Oczywiście, aby korzystać z takiej bramki dany użytkownik musi mieć także założone konto w obcej sieci komunikacji natychmiastowej, tak, aby bramka mogła wysyłać jego komunikaty jako pochodzące z danego konta. Dla obcych sieci bramka taka jest widoczna jako zwykły klient. Istnieją także transporty wykonujące inne czynności niż łączenie z inną siecią komunikacji natychmiastowej. Są transporty tłumaczące wysyłane wiadomości, transporty podające prognozę pogody, czy transporty pozwalające umieścić na stronie internetowej ikonkę pokazującą naszą obecność. Aby móc korzystać z danego transportu, trzeba do niego wysyłać komunikaty. Aby to robić, musimy znać jego adres. Stanowi to pewien problem, gdyż, jak wiemy, nie istnieje żadna centralna baza adresów Jabbera. Tutaj z pomocą przychodzą nam wbudowane w protokół mechanizmy odkrywania (discovery) serwisów. Dzięki nim możemy przeglądać transporty w podobny sposób, jak robimy to z plikami i katalogami na dysku.
Jabber używa jednolitego systemu adresowania wszelkich przesyłanych informacji. Każdy element w sieci Jabbera, taki jak klient, serwer, transport, bramka, posiada unikalny identyfikator, tak zwany JID (Jabber ID). Identyfikator ten składa się z trzech części: opcjonalnej nazwy użytkownika, nazwy domeny oraz opcjonalnego identyfikatora zasobu. Nazwa użytkownika, jeśli występuje, oddzielona jest od nazwy domeny znakiem @, natomiast nazwa domeny od identyfikatora zasobu znakiem /, dzięki czemu JID jest poprawnym URI (Universal Resource Identifier). Nazwa użytkownika najczęściej oznacza konkretną osobę posiadającą zasoby na serwerze, ale może także oznaczać na przykład nazwę pokoju na serwerze konferencji. Nie można w niej używać takich znaków jak ", &, ', /, :, <, >, czy @ i nie powinna ona mieć więcej niż 256 bajtów. Nazwa domeny musi być poprawną nazwą, którą można przypisać do numeru IP odwołując się do serwera DNS. Jest ona wykorzystywana do budowania połączeń TCP pomiędzy węzłami sieci. Można używać bezpośrednio numeru IP jako nazwy domeny, ale nie jest to zalecane. Jedynym ograniczeniem na identyfikator zasobu jest jego długość, która nie może przekraczać 256 bajtów. W przypadku klienta może on oznaczać komputer, z którego użytkownik łączy się z siecią Jabbera, miejsce w którym przebywa lub po prostu program z którego korzysta. Identyfikuje on konkretne połączenie lub sesję. Ten sam użytkownik może mieć nawiązanych wiele połączeń z serwerem, pod warunkiem, że ich identyfikatory zasobów są różne. Kiedy wysyłamy wiadomość do użytkownika, nie musimy podawać jego identyfikatora zasobu – wówczas to serwer podejmie decyzję gdzie dokładnie powinien dany komunikat zostać wysłany.
Kiedy jakiś element (klient, serwer, bramka) sieci Jabber chce nawiązać łączność z innym elementem, robi to za pomocą tak zwanego strumienia XML. Nawiązywane są dwa połączenia TCP, przez które przesyłane są dane w postaci XML, w jednym kierunku przez jedno połączenie, w kierunku przeciwnym przez drugie. Dane takie mają postać rosnącego stopniowo dokumentu XML. Każdy z komunikujących się obiektów dokleja
do swojego wychodzącego strumienia tak zwane urywki XML, będące poprawnymi elementami XML. Zastosowanie do komunikacji języka XML wprowadza co prawda pewien, dość spory, narzut, jednak pozwala na naprawdę elastyczne używanie protokołu. Komunikaty wymieniane są na tyle rzadko, będąc przy tym relatywnie małymi porcjami danych, że narzut wprowadzony przez zastosowanie XML nie ma większego znaczenia.
Na pojedynczy strumień XML można patrzeć jak na rozbudowywany dokument, który w każdym stadium tej rozbudowy jest jednak poprawny – wszystkie otwarte tagi, poza otwierającym strumień, są zamknięte, wszystkie elementy są kompletne. Jednak w kontekście Jabbera lepiej jest patrzeć na parę strumieni XML jak na dialog – poszczególne elementy strumienia są zapytaniami, odpowiedziami, albo po prostu powiadomieniami.
Klienci nie nawiązują ze sobą bezpośrednich połączeń – nie jest to możliwe, gdyż nie mogą oni przecież znać swoich adresów czy numerów IP. Jedyne co znają, to swoje JID, a więc nazwy użytkowników i serwerów. Cała komunikacja jest kierowana przez serwery.
Gdy serwer otrzymuje jakąś wiadomość, sprawdza, do kogo jest ona kierowana. Większość urywków XML zawiera adres docelowy. Jeśli wiadomość jest kierowana do odbierającego ją serwera, lub też do użytkownika na tym serwerze, wówczas jest ona odpowiednio przetwarzana. Jeśli natomiast nazwa domeny w adresie nie zgadza się z nazwą odbierającego serwera, serwer ten próbuje nawiązać łączność z serwerem adresata i przesłać wiadomość do niego. Połączenie takie jest utrzymywane jeszcze przez pewien czas, gdyż jest duże prawdopodobieństwo, że trzeba będzie przez nie przesłać więcej wiadomości.
Wpisywanie adresu JID przy wysyłaniu wiadomości nie jest zbyt wygodne. Dlatego więc, podobnie jak programy pocztowe mają często książki adresowe, tak w Jabberze występuje ich odpowiednik, czyli listy znajomych. Wystarczy kliknąć na nazwę znajomego na takiej liście, aby rozpocząć z nim rozmowę. Także wiadomości, które od niego przyszły, zaznaczone będą przy jego nazwie. Listy znajomych mogą być dla wygody i łatwości utrzymania porządku podzielone na grupy. Jednak lista znajomych to coś więcej, niż tylko książka adresowa. Za zgodą znajomego dodanego do takiej listy, możemy być informowani o jego obecności. Zgoda taka jest jednorazowa (choć można ją anulować) i nosi miano autoryzacji.
Wiele komunikatorów natychmiastowych oferuje informację o obecności użytkowników, nie wymagając przy tym żadnej zgody, jak na przykład Gadu-Gadu, lub też sprawdza, czy dany użytkownik wyraził zgodę tylko w aplikacji klienta, jak miało to miejsce w ICQ. Oczywiście bardzo szybko pojawiły się poprawione
wersje aplikacji klienta, nie wymagające zgody drugiej osoby. Jabber chroni naszą prywatność. Co prawda dodać do listy znajomych możemy kogokolwiek i kiedykolwiek, jednak bez jego zgody i tak nie będziemy otrzymywać informacji o jego obecności. Autoryzacja sprawdzana jest po stronie serwera tego użytkownika, którego obecność chcemy znać – nie ma więc mowy o ominięciu jej przy użyciu przerobionych klientów czy serwerów. Lista znajomych przechowywana jest na serwerze. Tam także trzymane są wszelkie informacje o autoryzowanych znajomych. Kiedy klient wysyła do serwera komunikat o zmianie swojej obecności (lub też po prostu przerywa połączenie), serwer przekazuje tą informację do wszystkich autoryzowanych na jego liście znajomych. Informacja ta może być prostym powiadomieniem o zalogowaniu czy wylogowaniu się, ale może także zawierać wiadomość zostawioną przez użytkownika albo nawet być powiadomieniem o tym, że użytkownik właśnie piszę do nas wiadomość – co jest przydatne przy dłuższych rozmowach. Przechowywanie listy znajomych na serwerze ma także tą niewątpliwą zaletę, że użytkownicy mają dostęp do niej niezależnie od tego, czy zalogują się ze swojego komputera w domu, w pracy czy też z drugiego końca świata – lista wędruje
wraz z nimi.
XMPP pozwala na jeszcze lepszą ochronę naszej prywatności dzięki wprowadzeniu tak zwanych list prywatności
(privacy lists). Dzięki nim możemy dość szczegółowo definiować reguły blokowania przychodzących do nas komunikatów oraz przychodzących i wychodzących powiadomieniach o obecności.
Jabber daje się użyć do całej gamy zastosowań. Podobnie jak protokół HTTP, Jabber jest doskonałym szkieletem do tworzenia aplikacji.
Różnego rodzaju skrypty to chyba najprostszy sposób na dodanie nowej funkcjonalności do Jabbera. Są to proste programy, najczęściej po prostu wysyłające komunikat, uruchamiane automatycznie w momencie zajścia jakiegoś zdarzenia, lub też uruchamiane przez użytkownika, aby w prosty sposób wykonać zapisane w nich, bardziej skomplikowane czynności. Skrypt taki najczęściej zaczyna swoje działanie od zalogowania się do serwera, używając konta swojego właściciela, bądź też konta specjalnie do tego celu założonego. Następnie wykonywane są wszystkie wymagane czynności, jak na przykład wysłanie komunikatu, ściągniecie z serwera i zapisanie listy znajomych, wysłanie zapisanej listy znajomych na serwer, czy też odebranie oczekujących wiadomości – możliwości jest wiele. Po wykonaniu swojej pracy skrypt rozłącza się i kończy swoje działanie.
Bot to bardziej zaawansowany program. Najczęściej korzysta on z własnego, specjalnie założonego konta. W przeciwieństwie do skryptów, boty nie kończą pracy krótko po uruchomieniu – najczęściej działają, oczekując na komunikaty, zmiany obecności czy inne wydarzenia, na które mają reagować. Za pomocą botów można zaimplementować większość serwisów. Możemy odpowiadać na przysłane komunikaty, monitorować obecność użytkowników, którzy autoryzowali tego bota, prowadzić logi konferencji. Jednak boty mają swoje ograniczenia – przez serwer traktowane są jak zwykli użytkownicy – nie mają zatem dostępu do informacji, do których zwykły użytkownik nie ma dostępu, jak obecność osób, które bota nie autoryzowały, komunikaty wysłane do innych użytkowników, czy szczegóły ustawień kont użytkowników.
Transporty są najbardziej chyba, poza modyfikacją samego serwera, metodą na rozszerzenie funkcjonalności Jabbera. Zamiast tłumaczyć przysyłane komunikaty z jednego protokołu na inny, jak robią to bramki, transporty mogą przecież reagować na przysłane komunikaty, oraz generować własne – tak, jakby pochodziły one od użytkowników innej sieci komunikacji natychmiastowej. O ile skrypty i boty mogą być ustawione przez każdego użytkownika, o tyle transporty są podłączane bezpośrednio do serwera, a to może zrobić tylko administrator tego serwera. Na szczęście możliwe jest korzystanie z transportów na wielu różnych serwerach na raz, możemy więc zawsze postawić własny serwer, bez użytkowników, podłączyć do niego nasz transport i korzystać z niego do woli. Transporty wymagają często, aby korzystający z nich użytkownicy wprowadzili pewne dodatkowe dane (jak na przykład, w przypadku bramek, dane dotyczące swojego konta w inne sieci komunikacji natychmiastowej) oraz autoryzowali się – tak, aby z danych tych nie mogły korzystać osoby niepowołane. Dla wygody użytkownika autoryzacja taka jest najczęściej jednorazowa – nie trzeba jej ponawiać przy każdym zalogowaniu do serwera Jabbera.
Podstawowy protokół Jabbera jest w zasadzie zgodny z protokołem *XMPP*, opisanym szczegółowo w RFC3920, oraz RFC3921, dlatego tutaj opiszę tylko podstawowe zagadnienia. Jednak XMPP to nie cały Jabber – wszelkie rozszerzenia opisane są w tak zwanych JEP, tworzonych przez Jabber Softoware Foundation. Są to otwarte dokumenty, o cyklu życia podobnym do RFC.
[…]
Wydawałoby się, że protokół tak dobrze dostosowany do jednego celu, jakim jest wymiana krótkich komunikatów pomiędzy ludźmi, musi być specjalizowany i nie nadaje się do innych zastosowań. Jednak specyfika Jabbera, jego rozszerzalność i uniwersalność powodują, że może on być i jest z powodzeniem wdrażany do najróżniejszych zastosowań.
To jest podstawowe zastosowanie. Jabber umożliwia dwóm osobom na zdalną rozmowę za pomocą krótkich wiadomości. Wiadomości mogą przyjmować postać wyskakującego okienka z tekstem, czy też okna rozmowy podobnego do “czatów”. W tekście mogą się pojawiać dodatkowe elementy, jak emotikony, adresy stron, adresy e-mail. Korzystając z odpowiednich serwisów, możemy także urządzić konferencję, albo nawet telekonferencję. Istnieją aplikacje klienckie rozszerzone o takie przydatne pomoce, jak tablica do rysowania, zdjęcia rozmówców czy obsługę kamer internetowych.
Bramki Jabbera to nie tylko połączenie z innymi sieciami komunikacji natychmiastowej. Istnieją także transporty wysyłające przysłanie do nich komunikaty jako SMS. Przykładem może być na przykład serwis prowadzony przez aspsms.com.
W bardzo prosty sposób możemy skonfigurować sobie procmail tak, aby za każdym razem, gdy dostajemy nowy list (lub tylko dla listów spełniających określone wymagania), wysyłany był do nas odpowiedni komunikat. Jeśli chcemy, możemy w tym komunikacie nawet przesłać cały list. Bardziej zaawansowana technologia pozwala, przy użyciu odpowiedniego transportu, wysyłać i odbierać listy za pomocą naszego komunikatora. Choć trzeba przyznać, że programy pocztowe są do tego lepiej przystosowane.
Coraz więcej pojawia się modyfikowalnych w zautomatyzowany sposób stron. Czy są to wiki, których zawartość może zmienić każdy, czy też bardziej zaawansowane systemy zarządzania treścią, czy wreszcie zwykłe fora dyskusyjne – w każdym z tych rozwiązań mamy do czynienia ze zmianami, które mogą być wprowadzone o dowolnej porze przez wielu użytkowników. Śledzenie takich zmian może być trudne, pomimo wprowadzenia udogodnień, w rodzaju powiadamianie o zmianach pocztą czy też protokołów syndykacji treści, takich jak RSS. Z pomocą może przyjść nam Jabber – powiadamianie o zmianach pocztą można łatwo zastąpić wysyłaniem komunikatów Jabbera, RSS może być z łatwością obsługiwany poprzez transport, a do tego zyskujemy nowe opcje – jak na przykład wyświetlanie Jabberowej obecności danego użytkownika na forum.
Oddzielną kategorię aplikacji sieciowych stanowią tak zwane blogi, będące czymś w rodzaju prowadzonego w internecie pamiętnika. Oczywiście dodawanie nowych wpisów odbywa się często i powinno być jak najprostsze. A czy może być ono prostsze niż wysłanie na odpowiedni adres tekstu wpisu w postaci wiadomości natychmiastowej? Do tego możemy dołączyć zdjęcie lub obrazek (korzystając z opcji przesyłania plików). Możemy też oczywiście, tak jak w przypadku wymienionych wcześniej aplikacji sieciowych, wysłać informację o wprowadzonych zmianach wszystkim zainteresowanym znajomym.
Jabber doskonale nadaje się do przesyłania informacji o wydarzeniach. Z łatwością, czy to używając skryptów, botów czy transportu, możemy stworzyć własną rozgłośnię wiadomości
, rozsyłającą informację do zapisanych do niej użytkowników. Wiadomości mogą być wysyłane raz dziennie, albo natychmiast po ich opracowaniu. Mogą być podzielone tematycznie, z możliwością zapisania się tylko na niektóre rodzaje wiadomości.
Jednym z bardzo istotnych rodzajów wiadomości mogą być wiadomości giełdowe. Komunikacja natychmiastowa nadaje się do ich przesyłania szczególnie dobrze, gdyż z reguły są one wiadomościami dość pilnymi – bardzo dużo zależy od szybkości reakcji. W tym przypadku aplikacje oparte na przeglądarkach internetowych nie zdają egzaminu – nie ma w nich sposobu na reagowanie na wydarzenia – jedynym sposobem na to, aby być na bieżąco jest ciągłe odświeżanie strony, a to obciąża serwer i łącza, oraz daje wrażenie powolności aplikacji. W przypadku Jabbera, problem taki nie istnieje – wiadomości otrzymujemy dokładnie wtedy, gdy są potrzebne, a odpowiedzi na pytanie o kupno czy sprzedaż akcji możemy udzielić błyskawicznie – dzięki czemu mamy więcej czasu na zastanowienie i analizę sytuacji.
Nawet bardzo proste boty często posiadają funkcję przypominania o terminach czy wydarzeniach, które im się uprzednio wprowadziło do pamięci. Użycie do tego celu protokołu Jabber ma tą niewątpliwą zaletę, że przypomnienie otrzymamy niezależnie od tego, przy jakim komputerze pracujemy. Nie musimy dzielić naszego terminarza na dwie części, zastanawiając się czy dany termin należy wpisać do programu w domu, czy w pracy. Po prostu podajemy botowi czas i opis, a przypomnienie dotrze do nas gdziekolwiek zalogujemy się do Jabbera.
Można stworzyć mnóstwo bardzo różnorodnych serwisów opartych na wymianie komunikatów. Słowniki, encyklopedie, kalendaria, horoskopy, informacje o prognozie pogody, etc. – wszystko to można zaimplementować w postaci prostych botów lub transportów.
Jabber może być z łatwością wykorzystany do automatycznego zgłaszania wszelkiego rodzaju awarii i niebezpiecznych sytuacji na serwerach. Często możliwe jest wysłanie ostrzeżenia jeszcze zanim sytuacja stanie się na tyle poważna, że uniemożliwiona zostanie wszelka komunikacja. Dotychczas popularne powiadamianie o takich sytuacjach poprzez pocztę elektroniczną jest niestety często zbyt powolne – nawet, jeśli ustawimy automatyczne powiadamianie o poczcie, to i tak przecież odbywa się ono na zasadzie regularnego odpytywania serwera, co nie zapewnia szybkiej reakcji, a do tego zwiększa obciążenie samego serwera.
Wiele urządzeń, jak na przykład switche i sprzętowe routery, posiadają tak zwaną konsolę konfiguracyjną – po połączeniu za pomocą telnetu, emulatora terminala, specjalnego programu do zarządzania, lub po prostu wejściu na stronę udostępnianą przez takie urządzenie, możemy dokonywać zmian w konfiguracji oraz kontrolować stan urządzenia. Jednak rozwiązania te mają swoje wady. W przypadku telnetu i emulatora terminala trudno jest wpisywać komendy, gdy cały czas na ekranie pojawiają się komunikaty związane ze stanem urządzenia. W przypadku strony nie jesteśmy informowani o zmianach w urządzeniu dopóki nie klikniemy odśwież. Dedykowane programy wymagają zainstalowania, co najczęściej ogranicza nam dostęp do jednego tylko komputera. Jabber ma w swoim protokole rozszerzenia przeznaczone specjalnie do takich zastosowań. Co prawda nie ma jeszcze urządzeń, które potrafiłyby używać Jabbera jako swojej konsoli, można jednak osiągnąć ten sam efekt pośrednio, używając transportu tłumaczącego pomiędzy Jabberem a SNMP.
Istnieje wiele złożonych systemów zgłaszania błędów, takich jak BugZilla czy FlySpray. Pozwalają one w sposób wygodny zgłosić nowo wykryte błędy w oprogramowaniu, a także śledzić historię błędów już wprowadzonych, przydzielać je do naprawienia różnym członkom zespołu, zamieszczać łatki i poprawki. Jabber może tu być wykorzystany, podobnie jak w przypadku CMS, do informowania o wszelkich zmianach w takim systemie odpowiednich osób, ale także można go wykorzystać do zgłaszania samych błędów.
Wiele firm prowadzi tak zwane gorące linie, czyli po prostu numer telefonu, pod którym dyżuruje osoba kompetentna, mająca za zadanie pomagać użytkownikom w rozwiązywaniu problemów z danym produktem. Jednak telefon nie jest najlepszym środkiem komunikacji w takiej sytuacji, szczególnie gdy chodzi o problemy z oprogramowaniem. Największa część rozmowy w takich przypadkach najczęściej polega na czytaniu przez użytkownika komunikatów wyświetlonych przez komputer, oraz na dyktowaniu przez pracownika pomocy technicznej poleceń, które użytkownik ma wpisać. Jeśli do tego rozmowa odbywa się po polsku, a polecenia i komunikaty są po angielsku, to często dochodzi do pomyłek i nieporozumień. Podobnie zorganizowana pomoc techniczna poprzez pocztę elektroniczną rozwiązuje ten problem, ale jest niestety zbyt powolna – użytkownik najczęściej chce rozwiązać swój problem jak najszybciej. Pomoc techniczna poprzez Jabbera wydaje się być bardzo dobrym rozwiązaniem. Komunikacja przebiega szybko, jak przy rozmowie telefonicznej, ale na piśmie, jak w przypadku poczty elektronicznej. Dodatkowo, dzięki rozszerzeniom protokołu Jabber możliwe jest korzystanie z ’’‘tablicy’’’, na której można umieszczać przykładowe ikonki, zaznaczać w którym miejscu należy kliknąć, czy też umieścić zrzut ekranu.
Jabber może być dużą pomocą przy nauczaniu. Możliwe jest nie tylko zdalne prowadzenie wykładów, konferencji i ćwiczeń, ale także nadzór nauczyciela nad uczniem. Dzięki powiadamianiu o obecności nauczyciel może łatwo sprawdzić, czy uczeń odebrał wiadomość od niego, a dzięki odpowiednim rozszerzeniom może nawet dowiedzieć się ile czasu uczeń pracuje z danym programem, w jakich godzinach, etc. Nauczyciel może w łatwy sposób podawać wyniki testów, wysyłać zadania domowe, odpowiadać na pytania w każdej chwili, gdy tylko jest dostępny. Jednocześnie nie pracuje przez cały czas, pytania zadane przez uczniów czekają do chwili ich odebrania. Dzięki zastosowaniu formularzy możliwe staje się wypełnianie testów i pisanie sprawdzianów poprzez Jabbera – i to z możliwością natychmiastowej kontroli czasu i poprawności odpowiedzi. Przesyłanie plików pozwala na pewniejszy niż w przypadku poczty elektronicznej sposób na składanie projektów.
Nic nie szkodzi na przeszkodzie aby tak zmodyfikować bramkę, żeby zamiast przesyłać komunikaty pomiędzy dwoma sieciami, przesyłała je do tej samej sieci, ale w pewien sposób zmodyfikowane. Jedną z możliwości takiej modyfikacji jest tłumaczenie automatyczne, dzięki któremu możemy prowadzić rozmowę praktycznie w każdym języku świata (pod warunkiem, że ktoś napisze program tłumaczący, oczywiście). Dzięki krótkiemu czasowi reakcji, niedoskonałości automatycznego tłumaczenia nie przeszkadzają w rozmowie – łatwo jest korygować niezrozumiałe zdania, poprosić o powtórzenie wypowiedzi przy użyciu innych słów.
Istnieje mnóstwo bibliotek przeznaczonych do obsługi Jabbera – zarówno bardzo prostych, o podstawowej jedynie funkcjonalności, jak i bardzo zaawansowanych. Biblioteki te można podzielić ze względu na ich przydatność w implementowaniu poszczególnych składników sieci Jabbera. Najprostsze z nich pozwalają na napisanie klienta, bota lub prostego skryptu. Bardziej złożone pozwalają napisać bramkę lub inny transport. Przy użyciu najbardziej zaawansowanych tworzy się serwery.
Pomimo faktu, że oryginalny serwer Jabbera napisany jest w C, nie ma dostępnych bibliotek przeznaczonych do pisania tego typu zaawansowanych aplikacji. Biblioteki pozawalające pisać komponenty w C to iksemel, libstrophe i loudmouth, natomiast dla C++ możemy wybrać JECL i oajabber. Spośród bibliotek przeznaczonych do pisania klientów Jabbera wymienić można Acid, IP*Works, Iris, jabberoo, oraz XMPP Client Daemon.
Tutaj mamy do wyboru dość szeroki repertuar dobrej jakości bibliotek. Poczynając od JSO, nadającej się nawet do tworzenia serwerów, poprzez Echomine Muse, JabberBeans, JabberWookie i Yaja, a skończywszy na bibliotekach klienckich, takich jak micro-jabber czy Smack.
Python wydaje się być szczególnie przyjaznym językiem dla użytkowników Jabbera. Część biblioteki Twisted odpowiedzialna za Jabbera z powodzeniem może być użyta nawet do napisania serwera. Nieco prostsze są takie biblioteki jak jabber.py, PyXMPP czy xmpppy, pozwalające na pisanie zarówno transportów jak i aplikacji klienckich.
Istnieją także biblioteki Jabbera dla wielu innych języków. Dla PHP mamy Class.Jabber.PHP oraz PHPJabberClass, dla Perla użyć możemy Jabber::Connection, Net::Jabber, oraz Net::XMPP. Są także biblioteki takie jak FML dla Flasha, czy JSJaC dla języka JavaScript. Jeśli przenośność nie jest ważna, skorzystać można także z bogatej kolekcji bibliotek COM i .NET.