1. HUB i pobieranie danych o serwerze

czymy si z serwerem idi.tlen.pl na porcie 80, a nastpnie
wysyamy zapytanie:

GET /4starters.php?u=identyfikator&v=10 HTTP/1.0
Host: idi.tlen.pl

Gdzie identyfikator to nasz login tlenowy, np. matijozef
W efekcie otrzymuje odpowied w formacie XML

<t s='s1.tlen.pl' p='443' v='48' c='0' i='192.168.1.1'>48</t>

W parametrze "s" dostajemy nazw hosta ktry bdzie serwerem dla
naszego poczenia, "p" to port, dane zawarte w "v" i "c" s bliej
nieokrelone. Parametr "i" natomiast to IP z ktrego poczylimy.
Zawarto tagu gwnego <t></t> rwnie jest bliej nieokrelona.

2. Otwieranie sesji (streamu)

Po poczeniu do waciwego serwera, otrzymanego od huba, naley
otworzy sesj. Jest to rwnoznaczne z przekazaniem serwerowi informacji,
eby zacz si nami interesowa, oraz, eby przesa nam identyfikator
sesji. W tym celu wysyamy:

<s v='2'>

Tag nie jest zamknity, gdy jest to otwarcie sesji. Cao dzieje si
w obrbie tego tagu, dopiero przy rozczeniu jest on zamykany.

Serwer odpowie nam

<s i='3FBA8D6F'>

Zawarto "i" to identyfikator sesji, powinnimy go zachowa, gdy bdzie
jeszcze przydatny. 

2.1. Podtrzymanie streamu

Aby serwer nie powiedzia nam, e nas nie lubi, trzeba mu wysya co
jaki czas pakiet typu keepalive. Z obserwacji wynika, e co minut
musimy wysya pakiet o zawartoci "  \t  ", czyli dwie-spacje-tabulator
-dwie-spacje.

3. Autoryzacja

Kolejnym etapem czenia jest autoryzacjia. Procedura
wysyania hasa zostaa zmieniona w stosunku do Jabbera. Trudno jest to opisa,
w sumie nawet nie wiem jak to do koca dziaa (PP do tablicy), ale w auth.c
s wszystkie potrzebne funkcje. Wracajc jednak do samej autoryzacji.
Wysyamy:

<iq type='set' id='3FBA8D6F'><query xmlns='jabber:iq:auth'><username>matijozef
</username><digest>hash</digest><resource>t</resource></query></iq>

Pole "id" to wczeniej otrzymany identyfikator sesji. Pod username podstawiamy
nasz identyfikator, w tym przypadku matijozef. Zawarto digest to przepuszczone
przez SHA1 poczenie 8bitowego hasha hasa z identyfikatorem, czyli to 
czego do koca nie rozumiem.

W przypadku zatwierdzenia hasa, otrzymamy

<iq type='result' id='3FBA8D6F'/>

Jest to rwnoznaczne z tym, e wszystko jest OK i moemy dalej si bawi
na tym podwrku. Jeeli jednak ze haso, to wtedy otrzymujemy: 

<iq type='error' id='3FBA8D6F'/>

Jak dostaniemy tak zawarto, to papa. Serwer nas rozcza. 

4. Micho protokou, czyli zabawa na podwrku

4.1. Pobieranie ksiki kontaktowej

Pobranie ksiki kontaktowej, czyli rostera, to jeden z najwaniejszych
elementw po zalogowaniu. Trudno korzysta z komunikatora bez tego. Umieciem
to w podpunckie dlatego, e wbrew pozorom nie jest konieczne. Jeeli program
ma wysa tylko wiadomo, to mona zaoszczdzi te kilka pakietw nie
pobierajc rostera. Przechodzc jednak do rzeczy.

Po zalogowaniu i autoryzowaniu wysyamy:

<iq type='get' id='GetRoster'><query xmlns='jabber:iq:roster'></query></iq>

Serwer odpowie:

<iq type='result' id='GetRoster' from='matijozef@tlen.pl/t'><query
xmlns='jabber:iq:roster'><item jid='libtlendev@tlen.pl' name='libtlendev'
subscription='both'><group>grupa</group></item>.....</query></iq>

Parametr from w zapytaniu to nasz wasny identyfikator. Cao ksiki
przesyana jest jako wiele tagw <item> wewntrz <query>. Parametry
kadego elementu to jid - identyfikator tlenowy, name - nazwa, 
subscription - poziom autoryzacji (w tlenie moemy by bez autoryzacji
w ogle, oczekiwa na autoryzacj drugiej strony, lub druga strona moe
nas mie autoryzowanych, ale my jej nie). Wewntrz kadego tagu <item>
znajduje si tag <group>, ktrego zawartoci jest nazwa grupy, do ktrej
kontakt naley. 

4.2. Zarzdzanie uytkownikami

4.2.1. Dodawanie nowego uytkownika

Aby doda nowego uytkownika najpierw prosimy go o zgod

<presence to='libtlendev@tlen.pl' type='subscribe'/>

Jeeli si zgodzi, czyli otrzymamy pakiet

<presence from='libtlendev@tlen.pl' type='subscribed'/>

moemy doda go do wasnej ksiki, wiedzc, e on si na to zgadza.
Dokonujemy tego tak:

<iq type='set' id='3FBA8D6F'><query xmlns='jabber:iq:roster'><item name='libtlendev' jid='libtlendev@tlen.pl'></item></query></iq>

Parametr id to identyfikator sesji. W name przekazujemy zaurlencodowan
nazw uytkownika (bo mog by pliterki), w jid za jego identyfikator
tlenowy.

<WATCH OUT USING THAT!> nie jestem pewien czy dobrze napisaem, musz
przewertowa kod ...

4.3. Informacje o stanie

Zaraz po odebraniu ksiki adresowej powinnimy si pokaza, do tego celu
wysyamy standardowego XMLa typu presence.

Dziaanie stanw jest bardzo proste. Aby wysa nasz stan, lub go zmieni,
wysyamy

<presence><show>typ_stanu</show><status>opis</status></presence>

typ_stanu to jeden z poniszych:

    - available - dostpny
    - away - zajty/odszedem od komputera
    - chat - chtny do rozmowy
    - xa - bd pniej
    - dnd - nie przeszkadza

Dodatkowe stany to invisible oraz unavailable, jednak wysyane s w inny 
sposb. O tym pniej. Bardzo wane jest to, e w tlenie *WSZYSTKIE* 
dane tekstowe, w tym przypadku opis, wysyane s w formacie ISO 8859-2
przepuszczone przez UrlEncode! W przypadku gdy kto zmienia stan, dostajemy
od serwera

<presence from='identyfikator@tlen.pl/t'><show>...</show><status>...</status></presence>

Reguki j.w.

4.3.1. Stany dodatkowe, czyli invisible i unavailable

Invisible, czyli niewidoczny, w najnowszej wersji protokou wysyany
jest tak jak niedostpny. Konstrukcja pakietu:

<presence type='invisible'></presence>

Druga strona dostanie w tym przypadku zwyk informacj, e nas ju nie ma,
praktycznie nie do wykrycia, chod pono si da.

Wysanie statusu o niedostpnoci jest rwnoznaczne z rozczeniem si
od serwera i zamkniciem streamu, a konstrukcja zapyta jest opisana 
w rozdziale 5 - Zamykanie sesji (streamu).

4.4. Wiadomoci

Przesyanie wiadomoci jak ich odbierane jest banalne. Wysyamy XMLa:

<message to='identyfikator@tlen.pl/t' type='typ'><body>tresc</body></message>

identyfikator to nasz rozmwca. Typ to jeden z dwch: 

    - normal - wiadomo zwyka
    - chat - wiadomo typu rozmowa
    
Tre oczywicie musi zosta zakodowana poprzez urlencode. Otrzymujc
wiadomoci przychodzi taki sam pakiet, tyle, e zamiast parametru to jest
parametr from okrelajcy nadawc.

4.4.5. Wiadomo z bramki WWW

Wiadomo wysana z bramki WWW na Tlen.pl nie dociera do nas jako zwyky
mesg, jest to specjalnie spreparowany pakiet typu webmsg. 

Konstrukcja pakietu, ktory otrzymamy to:

<w f='ktos@tlen.pl' e='adresemailktosia@serwer.pl' s='http://strona.z.bramka.pl'>tresc wiadomosci</w>

W polu f mamy identyfikator tlenowy osoby, ktra nam wiadomo wysaa.
Pole e zawiera adres e-mail tej samej osoby, za pole s to adres strony,
na ktrej jest bramka, z ktrej zostaa wysana wiadomo. Zawarto taga
<w> to tre wiadomoci (oczywicie urlencoded!)

4.4.6. Reklamy - czyli to, co tygrysy lubi najbardziej

Mechanizm rozsyania do klientw Tlenu reklam w postaci wyskakujcych
okienek (nie myli z bannerami), to nic innego jak zwyka wiadomo
z pewnymi dodatkami.

Wiadomo reklamowa przychodzi od identyfikatora b73@tlen.pl, a zawarto
pakietu to:

<message from='b73@tlen.pl' to='user@tlen.pl'><subject>a</subject><body>
[dane-reklamy]</body></message>

[dane-reklamy] to zakodowany urlencodem kolejny XML wygladajacy tak:

<a t='5'><u>http://212.126.20.25/reklama/plus/nokia/index_400.html</u><w>416</w><h>442</h><c>Plus GSM - Nokia N-Gage</c></a>

Co oznacza parametr - t - nie wiem, nie jest potrzebny. W tagu <u> zawarty
jest adres strony, ktra ma si wywietli w popupie. <w> to szeroko popupa,
<h> to jego wysoko, <c> to za to nazwa reklamodawcy pokazujca si w tytule
okienka. Cay przykadowy pakiet wyglda wic np. tak:

<message to='matijozef@tlen.pl' from='b73@tlen.pl'><body>%3Ca+t%3D%275%27%3E%3Cu%3Ehttp%3A%2F%2F212.126.20.25%2Freklama%2Fplus%2Fnokia%2Findex_400.html%3C%2Fu%3E%3Cw%3E416%3C%2Fw%3E%3Ch%3E442%3C%2Fh%3E%3Cc%3EPlus+GSM+-+Nokia+N-Gage%3C%2Fc%3E%3C%2Fa%3E</body><subject>a</subject></message>

4.5. Powiadomienia

Od wersji 4.2 Tlenu dostpne s specjalne wiadomoci-powiadomienia. 
Jest to po prostu typing-notification + bajer zwany alertem dwikowym,
ktry wydaje u klienta dzwik dzwonka gdy takowy alert przyjdzie.

S trzy typy powiadomie. Pierwsze, to e uytkownik pisze - czyli
klasyczne typing notification. Ma ono identyfikator 't'. Drugie - to
Tlenowe rozszerzenie typing notification, informacja o tym, e
uytkownik przesta pisa. Wywoywane jest w windzianym kliencie
po 30 sekundach nieaktywnoci od wysania 't' i ma ono identyfikator
'u'. Ostatnie powiadomienie to soundalert i ma identyfikator 'a'. 

Aby wysa powiadomienie, wysyamy pakiet

<m to='znajomy@tlen.pl' tp='[t,u,a]'> // w tp jedno z wymienionych

W przypadku, gdy sami otrzymujemy powiadomienie, pakiet sformatowany
jest w sposb nastpujcy:

<m f='znajomy@tlen.pl' tp='[t,u,a]'> // w tp jedno z wymienionych

Znaczenie jest oczywiste.

4.6. Powiadomienie o nowej poczcie

W przypadku gdy na konto @o2.pl dostaniemy now poczt i jestemy zalogowani
do Tlenu, otrzymamy pakiet

<n f='ktostam@serwer.pl' s='temat listu'>

jest to zwyczajne powiadomienie o nowej poczcie.

5. Zamykanie sesji (streamu)

Wylogowanie oraz zamknicie sesji polega na wysaniu specyficznego pakietu
obecnoci (odnonik do 4.x tam gdzie presence), oraz zakoczeniu streamu. 

Wysyamy:

<presence type='unavailable'><show></show><status>Disconnected</status></presence>
</s>

Pierwszy pakiet powoduje, e stajemy si niedostpni, drugi natomiast zamyka
stream i serwer o nas zapomina.
