Implementace protokolu XMPP v JavaScriptu

České vysoké učenı́ technické v Praze
Fakulta elektrotechnická
ČVUT FEL katedra počı́tačů
Diplomová práce
Implementace protokolu XMPP v JavaScriptu
Bc. Jan Brůček
Vedoucı́ práce: Ing. Tomáš Novotný
Studijnı́ program: Elektrotechnika a informatika, strukturovaný, Navazujı́cı́ magisterský
Obor: Výpočetnı́ technika
leden 2011
ii
Poděkovánı́
V prvnı́ řadě bych rád poděkoval Ing. Tomáši Novotnému za vedenı́ této práce a za čas, který
mi věnoval při konzultacı́ch.
Dále bych chtěl poděkovat Anně Mı́rové a své rodině za to, že mi byli oporou nejen při tvorbě
této práce, ale i během celého studia.
iii
iv
Prohlášenı́
Prohlašuji, že jsem práci vypracoval samostatně a použil jsem pouze podklady uvedené v
přiloženém seznamu.
Nemám závažný důvod proti užitı́ tohoto školnı́ho dı́la ve smyslu §60 Zákona č. 121/2000 Sb.,
o právu autorském, o právech souvisejı́cı́ch s právem autorským a o změně některých zákonů
(autorský zákon).
V Praze dne 3.1.2011
.............................................................
v
vi
Abstract
This work presents result of analysis and development of XMPP library under Mozilla Application Framework and its implementation as ExtBrain Communicator extension for Mozilla
Thunderbird.
Abstrakt
Práce prezentuje výsledky analýzy a vývoje XMPP knihovny určené pro Mozilla Application
Framework. Dále popisuje realizaci rozšı́řenı́ poštovnı́ho klienta Mozilla Thunderbird nazvané
ExtBrain Communicator, které využı́vá tuto knihovnu.
vii
viii
Obsah
Seznam obrázků
xiv
Seznam tabulek
xv
1 Úvod
1
2 Specifikace cı́lů práce
2
2.1
Vymezenı́ cı́lů diplomové práce . . . . . . . . . . . . . . . . . . . . . . . . . . .
2
2.2
Požadavky na implementovaný systém . . . . . . . . . . . . . . . . . . . . . . .
2
2.3
Struktura práce ve vztahu k vytyčeným cı́lům . . . . . . . . . . . . . . . . . . .
3
2.4
Existujı́cı́ řešenı́ v Mozilla Application Frameworku . . . . . . . . . . . . . . . .
4
2.4.1
Sameplace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4
2.4.2
Instantbird . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4
2.4.3
Spicebird . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4
Ostatnı́ podobná řešenı́ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4
2.5.1
GTalk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
2.5.2
Facebook . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
2.5
3 Analýza a návrh řešenı́
3.1
6
XMPP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6
3.1.1
Úvod
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6
3.1.2
Standardizace a XEPy . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6
3.1.3
Protokol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
3.1.4
IM komunikace a online stavy . . . . . . . . . . . . . . . . . . . . . . . .
9
3.1.4.1
Message stanza . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
3.1.4.2
Presence stanza . . . . . . . . . . . . . . . . . . . . . . . . . .
10
3.1.4.3
IQ stanza . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11
Vyjednánı́ spojenı́ a jeho bezpečnost . . . . . . . . . . . . . . . . . . . .
11
3.1.5
ix
3.2
3.3
3.4
3.1.5.1
Průběh SASL . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12
3.1.5.2
PLAIN autentifikace . . . . . . . . . . . . . . . . . . . . . . . .
12
3.1.5.3
DIGEST-MD5 autentifikace . . . . . . . . . . . . . . . . . . . .
13
Mozilla Application Framework . . . . . . . . . . . . . . . . . . . . . . . . . . .
15
3.2.1
JavaScript . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
15
3.2.2
Komponenty frameworku . . . . . . . . . . . . . . . . . . . . . . . . . .
15
3.2.3
Vytvářenı́ rozšı́řenı́ Mozilla aplikace . . . . . . . . . . . . . . . . . . . .
17
3.2.3.1
Chrome URL . . . . . . . . . . . . . . . . . . . . . . . . . . . .
17
3.2.3.2
Chrome manifest a struktura add-onu . . . . . . . . . . . . . .
18
ExtBrain Communicator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
19
3.3.1
XMPP knihovna . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
19
3.3.2
Řešenı́ vı́ce souběžných XMPP spojenı́ . . . . . . . . . . . . . . . . . . .
21
3.3.3
Kontakty z adresářů a z rosteru . . . . . . . . . . . . . . . . . . . . . . .
22
3.3.4
Uživatelské rozhranı́ . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
23
Vývojové prostředı́ a použité nástroje . . . . . . . . . . . . . . . . . . . . . . .
25
4 Realizace
4.1
4.2
26
Knihovna XMPP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
26
4.1.1
Socket . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
26
4.1.2
Analýza XML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
27
4.1.2.1
Parser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
27
4.1.2.2
Fragmentace . . . . . . . . . . . . . . . . . . . . . . . . . . . .
28
4.1.3
Udržovánı́ spojenı́ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
29
4.1.4
Zpracovánı́ přijatého DOM . . . . . . . . . . . . . . . . . . . . . . . . .
29
4.1.5
Napojenı́ dalšı́ch komponent do XMPP kanálu . . . . . . . . . . . . . .
31
4.1.6
DIGEST-MD5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
31
Uživatelské rozhranı́ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
31
4.2.1
32
Seznam kontaktů . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
x
4.2.1.1
Slučovánı́ kontaktů z adresáře a z rosteru . . . . . . . . . . . .
33
4.2.1.2
Manipulace s kontakty
. . . . . . . . . . . . . . . . . . . . . .
35
4.2.1.3
Informace o kontaktu . . . . . . . . . . . . . . . . . . . . . . .
36
Konverzace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
36
4.2.2.1
Obsluha událostı́ . . . . . . . . . . . . . . . . . . . . . . . . . .
37
4.2.3
Historie konverzacı́ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
38
4.2.4
Okno nastavenı́ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
38
4.2.2
5 Testovánı́
41
5.1
Testovacı́ prostředı́ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
41
5.2
XMPP knihovna . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
41
5.3
Uživatelské rozhranı́ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
42
6 Závěr
43
Literatura
45
A Diagramy a obrázky
47
B Seznam použitých zkratek
50
C Instalačnı́ přı́ručka
51
C.1 Požadavky k instalaci . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
51
C.2 Instalace ExtBrain Communicatoru . . . . . . . . . . . . . . . . . . . . . . . . .
51
D Uživatelská přı́ručka
53
D.1 Nastavenı́ účtů . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
53
D.2 Nastavenı́ zobrazovaných adresářů . . . . . . . . . . . . . . . . . . . . . . . . .
54
D.3 Připojenı́ účtů . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
54
D.4 Započetı́ konverzace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
55
D.5 Úprava kontaktu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
56
D.6 Sloučenı́ kontaktu z rosteru s kontaktem z adresáře . . . . . . . . . . . . . . . .
56
xi
D.7 Zobrazenı́ historie konverzace . . . . . . . . . . . . . . . . . . . . . . . . . . . .
E Obsah přiloženého CD
57
59
xii
Seznam obrázků
3.1
Přı́klad komunikace pomocı́ IQ stanz . . . . . . . . . . . . . . . . . . . . . . . .
11
3.2
Mozilla Application Framework – XPConnect, zdroj: [3] . . . . . . . . . . . . .
16
3.3
Instalace XPI balı́ku do Mozilla aplikace . . . . . . . . . . . . . . . . . . . . . .
17
3.4
Návrh třı́dy XMPPSocket . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
19
3.5
Návrh třı́dy XMPP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
20
3.6
Návrh třı́dy Jabber . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
21
3.7
Návrh třı́dy Connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
21
3.8
Návrh třı́dy Contact . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
22
3.9
Uživatelské rozhranı́ hlavnı́ho okna . . . . . . . . . . . . . . . . . . . . . . . . .
23
3.10 Uživatelské rozhranı́ záložky s konverzacı́ . . . . . . . . . . . . . . . . . . . . .
24
3.11 Uživatelské rozhranı́ nastavenı́ . . . . . . . . . . . . . . . . . . . . . . . . . . . .
24
4.1
Seznam kontaktů . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
32
4.2
Box s informacemi o kontaktu . . . . . . . . . . . . . . . . . . . . . . . . . . . .
36
4.3
Záložka s konverzacı́ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
37
4.4
Modálnı́ okno nastavenı́ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
39
A.1 Přechody mezi stavy připojovánı́ XMPP klienta, zdroj: [2] . . . . . . . . . . . .
47
A.2 Návrh třı́d pro XMPP knihovnu . . . . . . . . . . . . . . . . . . . . . . . . . .
48
A.3 Návrh třı́d pro práci s kontakty . . . . . . . . . . . . . . . . . . . . . . . . . . .
49
C.1 Okno Add-ons
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
51
C.2 Potvrzenı́ instalace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
52
C.3 Potvrzenı́ instalace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
52
D.1 Okno Nastavenı́ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
53
D.2 Seznam kontaktů . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
54
D.3 Informace o stavu účtů . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
54
D.4 Nastavenı́ stavu jednotlivých účtů . . . . . . . . . . . . . . . . . . . . . . . . .
55
xiii
D.5 Kontextové menu kontaktu . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
55
D.6 Záložka s konverzacı́ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
56
D.7 Okno pro úpravu přiřazených JID . . . . . . . . . . . . . . . . . . . . . . . . .
57
xiv
Seznam tabulek
3.1
Struktura instalovatelného balı́ku rozšı́řenı́ . . . . . . . . . . . . . . . . . . . . .
18
4.1
SQLite tabulka historie konverzace . . . . . . . . . . . . . . . . . . . . . . . . .
38
4.2
SQLite tabulka nastavenı́ účtů . . . . . . . . . . . . . . . . . . . . . . . . . . .
40
xv
xvi
KAPITOLA 1. ÚVOD
1
1 Úvod
V současné době zažı́váme roustoucı́ trend v použitı́ aplikacı́ založených na výměně rychlých
zpráv, tzv. instant messagingu. Známy jsou zejména dı́ky zprostředkovánı́ komunikace mezi
lidmi, avšak použı́vané technologie nalézajı́ uplatněnı́ i v předávánı́ zpráv mezi počı́tači a jinými
elektronickými zařı́zenı́mi. Hlavnı́ výhodou těchto aplikacı́ je tzv. real-time komunikace, tedy s
minimálnı́m zpožděnı́m od odeslánı́ do doručenı́ zprávy.
Historie internetového instant messagingu1 se datuje již od konce 80. let 20. stoletı́, kdy jako
jedna z technologiı́ umožňujı́cı́ch rychlou výměnu zpráv mezi uživateli počı́tačů, vznikla sı́t’ IRC.
Masovému rozšı́řenı́ IM mezi běžné uživatele ale dopomohl až systém ICQ společnosti Mirabilis,
který byl spuštěn v roce 1996. S podobnými produkty se na trhu objevily také společnosti
America Online (AOL Messenger), Microsoft (MSN Messenger), IBM (Lotus Sametime) a dalšı́.
Společnou vlastnosti všech zmı́něných IM systémů je to, že použı́vajı́ proprietárnı́ protokol
a klientské aplikace. Přı́liš limitujı́cı́ licenčnı́ podmı́nky a nutnost běhu separátnı́ aplikace pro
každý z IM protokolů proto v roce 1998 vedly Jeremie Millera k započetı́ pracı́ na novém
open-source protokolu, který pojmenoval Jabber [11].
Komunita vývojářů, která se později okolo projektu vytvořila, pak v květnu roku 2000 vydala
prvnı́ oficiálnı́ verzi nového open-source serveru jménem jabberd 1.0. Projekt měl u technické
veřejnosti velký úspěch a vývojáři se rozhodli formalizovat použı́vaný protokol u Internet Engineering Task Force (IETF), organizace, která vyvı́jı́ a standardizuje internetové technologie.
Pracovnı́ skupina, která dostala tento protokol na starosti, ho pojmenovala Extensible Messaging and Presence Protocol, tedy zkráceně XMPP.
Dnes je již XMPP2 velmi vyspělým protokolem, celosvětově uznávaným standardem a
použı́vanou technologiı́ nejen pro zası́lánı́ zpráv mezi lidmi pomocı́ počı́tačů, telefonů nebo
sociálnı́ch sı́tı́. Své využitı́ nacházı́ i v čistě strojové komunikaci pro cloud computing, vzdálený
monitoring, ovládánı́ zařı́zenı́ připojených do sı́tě a podobně.
Pro XMPP existuje velké množstvı́ klientů pro různé platformy, některé z nich dokonce
podporujı́ i vı́ce jiných IM technologiı́. Cı́lem této práce bude vytvořit klienta v prostředı́
Mozilla Application Frameworku, konkrétně pro aplikaci Mozilla Thunderbird.
Mozilla Thunderbird je poštovnı́m klientem neziskové organizace Mozilla Foundation, která
zastřešuje vývoj několika internetových aplikacı́, jako je napřı́klad webový prohlı́žeč Mozilla
Firefox nebo právě zmiňovaný Mozilla Thunderbird. Mezi hlavnı́ výhody aplikacı́ Mozilla Foundation patřı́ to, že jsou open-source a licencované třemi licencemi MPL/GPL/LGPL.
1
2
V textu bude použito zkrácené označenı́ IM
často také označováno zkráceně jako Jabber
2
KAPITOLA 2. SPECIFIKACE CÍLŮ PRÁCE
2 Specifikace cı́lů práce
2.1
Vymezenı́ cı́lů diplomové práce
Hlavnı́mi cı́li této práce jsou implementace XMPP protokolu v jazyku Javascript v prostředı́
Mozilla Application Frameworku a jeho následná integrace do existujı́cı́ho rozšı́řenı́ – ExtBrain
Communicatoru.
• Základnı́m bodem bude realizace XMPP knihovny v Javascriptu, funkčnı́ v aplikaci
Mozilla Thunderbird (resp. ve všech aplikacı́ch, použı́vajı́cı́ch Mozilla Application Framework). Tato knihovna bude zajišt’ovat sestavenı́ spojenı́ s XMPP serverem včetně autentizacı́ uživatele a bude poskytovat rozhranı́ pro přı́stup k takto vytvořenému kanálu.
• Dalšı́m bodem bude vývoj rozšı́řenı́ pro Mozilla Thunderbird, nazvaného ExtBrain Communicator. Práce bude částečně vycházet z již realizovaného rozšı́řenı́, které pod vedenı́m
Ing. Novotného vytvořil jako bakalářskou práci David Jirovec [7]. Toto rozšı́řenı́ bude
využı́vat XMPP knihovnu realizovanou v prvnı́m bodě a poskytovat rozhranı́ pro IM
komunikaci pomocı́ vı́ce XMPP účtů přı́mo v poštovnı́m klientu Thunderbird.
Později je také plánováno zařazenı́ výsledku této práce do rodiny ExtBrain rozšı́řenı́, která si
kladou za cı́l co nejvı́ce zjednodušit kažodennı́ práci vývojářů softwaru při extrakci a manipulaci
s informacemi [9].
2.2
Požadavky na implementovaný systém
Vytvořená aplikace bude použı́vána jako rozšı́řenı́ v poštovnı́m klientu Mozilla Thunderbird.
Bude poskytovat možnost připojenı́ se do XMPP sı́tě, bude možné ji však také použı́vat bez
nastavených účtů jako panel, který slučuje kontakty z vybraných adresářů klienta do jediného
seznamu, a který bude jednoduše filtrovatelný.
Požadované vlastnosti lze shrnout do seznamu:
• XMPP knihovna bude podporovat zabezpečenı́ spojenı́ pomocı́ TLS, SSL.
• XMPP knihovna bude poskytovat rozhranı́ pro pozdějšı́ napojenı́ dalšı́ch aplikacı́ na kanál
XMPP, tedy napřı́klad integraci dalšı́ch rozšı́řenı́ protokolu.
• Bude implementována správa vı́ce XMPP účtů najednou.
KAPITOLA 2. SPECIFIKACE CÍLŮ PRÁCE
3
• Bude implementován komunikačnı́ klient v prostředı́ Mozilla Thunderbird, který bude
využı́vat vyvinutou XMPP knihovnu, a který bude umožňovat sloučenı́ kontaktů z adresářů poštovnı́ho klienta a kontaktů z jabber účtů.
2.3
Struktura práce ve vztahu k vytyčeným cı́lům
Tato diplomová práce je členěna do šesti kapitol vážı́cı́ch se k postupu při řešenı́ problému.
• Prvnı́ kapitolou je úvod, kde se čtenář seznámı́ se základy technologiı́, které budou v práci
použity.
• Dalšı́ kapitolu tvořı́ popis a specifikace cı́lů práce. V nı́ se čtenář seznámı́ s řešeným
problémem a požadavky na výsledné řešenı́.
• Navazuje kapitola obsahujı́cı́ analýzu a samotný návrh řešenı́. Zde se čtenář detailněji
seznámı́ s technologiemi a s výsledným vybraným postupem pro implementaci.
• Dalšı́ kapitolou je kapitola popisujı́cı́ samotnou implementaci projektu a zaměřujı́cı́ se
zejména na nestandardnı́ části aplikace.
• Předposlednı́ kapitola obsahuje popis testovánı́ výsledného produktu této práce.
• V závěru práce je zhodnoceno dosaženı́ vytyčených cı́lů práce a diskuse možného pokračovánı́ v implementaci vyvinutého projektu.
4
KAPITOLA 2. SPECIFIKACE CÍLŮ PRÁCE
2.4
2.4.1
Existujı́cı́ řešenı́ v Mozilla Application Frameworku
Sameplace
Sameplace je v současnosti jediný doplněk do Mozilla Thunderbirdu, který přidává možnost
komunikace přes XMPP. Funguje však pouze pro verze Thunderbird 2 a zatı́m nenı́ známo,
zda bude někdy k dispozici verze podporujı́cı́ Thunderbird 3. Poslednı́ změna v kódu, který je
licencován jako GPLv3, byla provedena v lednu 2010.
Sameplace pro svou funkčnost vyžaduje knihovnu xmpp4moz, která byla využita i v původnı́m
prototypu ExtBrain Communicatoru. Ukázala se však jako nevhodná, mimo jiné pro svou
nefunkčnost v zacı́lené verzi Thunderbirdu.
2.4.2
Instantbird
Instantbird je samostatná aplikace postavená na Mozilla Application Frameworku. V
současnosti je vydána ve verzi 0.2 a je založena na knihovně libpurple, která podporuje velké
množstvı́ komunkačnı́ch protokolů. Kromě XMPP tak napřı́klad ICQ, IRC, Lotus Sametime a
dalšı́.
Aplikace je velmi přı́jemně použitelná. Tı́m, že je samostatná, ale nenı́ přı́mo porovnatelná
s aplikacı́, která bude vyvinuta v rámci této práce.
2.4.3
Spicebird
Spicebird je také samostatná aplikace postavená na Mozilla Application Frameworku a
vycházejı́cı́ z Mozilla Thunderbirdu. Je zaměřena na spolupráci uživatelů, kteřı́ ji použı́vajı́,
tvůrci ji označujı́ jako collaboration application. Zjednodušuje práci tı́m, že poskytuje přı́stup
k webovým aplikacı́m při zachovánı́ pohodlı́ desktopové aplikace. Interně použı́vá xmpp4moz z
projektu Sameplace.
Podobně jako Instantbird ji ale nenı́ možné přı́mo srovnat s předmětem vývoje v této práci.
2.5
Ostatnı́ podobná řešenı́
XMPP jako standard je použit i jako základ komunikačnı́ch modulů některých známych
webových aplikacı́. Za všechny jsou zde uvedeny dva nejpoužı́vanějšı́: Google Talk společnosti
Google a Facebook Chat společnosti Facebook.
KAPITOLA 2. SPECIFIKACE CÍLŮ PRÁCE
2.5.1
5
GTalk
Google Talk1 je služba nabı́zená zdarma všem uživatelům e-mailové schránky společnosti Google
(GMail). Služba byla spuštěna v roce 2005 a kromě podpory XMPP použı́vá i knihovnu libjingle
pro přenos zvuku a videa. Protože Google Talk použı́vá standardnı́ XMPP, je možné se k serveru
připojit libovolným XMPP klientem. Podpora Google Talk bude zabudována i v aplikaci, která
bude vyvinuta v rámci této práce.
2.5.2
Facebook
S celosvětovým rozšı́řenı́m sociálnı́ sı́tě Facebook přišla i potřeba IM komunikace. Facebook,
podobně jako Google, sáhl po otevřeném standardizovaném řešenı́ v podobě XMPP. Na Facebook chat je také možné se připojit libovolným klientem, server ale nepodporuje některá
rozšı́řenı́ XMPP protokolu, která jsou běžná u standardnı́ch XMPP serverů nebo napřı́klad u
Google Talk. Pomocı́ rozšı́řenı́, které bude výsledkem této práce, se bude možné připojit i na
Facebook Chat.
1
bývá také zkracován jako GTalk
6
KAPITOLA 3. ANALÝZA A NÁVRH ŘEŠENÍ
3 Analýza a návrh řešenı́
3.1
3.1.1
XMPP
Úvod
Jak již bylo uvedeno výše, XMPP je protokol, který je založen čistě na standardizovaných a
otevřených technologiı́ch. Základnı́m stavebnı́m kamenem tohoto protokolu je XML1 . Veškerá
komunikace mezi entitami propojenými protokolem XMPP probı́há právě pomocı́ zpráv odpovı́dajı́cı́ch XML syntaxi.
Entity, propojené sı́tı́ XMPP se dělı́ na
• klient
• server
Na základě tohoto dělenı́ pak v sı́ti probı́hajı́ dva typy komunikace:
• klient – server (označované také c2s, z anglického ”client to server”)
• server – server (označované také s2s, z anglického ”server to server”)
Sı́t’ založená na XMPP je decentralizovaná. Každý klient je registrován na jediném serveru a
má přiřazen unikátnı́ identifikátor nazývaný JID – Jabber ID. JID je strukturován podobně jako
e-mailová adresa, tedy ve formátu [email protected]. Dı́ky tomuto schématu nenı́ nutné
zavádět centrálnı́ server, který by obsahoval seznam všech registrovaných uživatelů.
Protože je možné se přihlásit k XMPP serveru z vı́ce mı́st (respektive vı́ce zařı́zenı́) najednou, může být k JID ještě přidán identifikátor – tzv. resource, který jednoznačně určuje
jednotlivé klienty, připojené k serveru pomocı́ daného JID. Formát takového identifikátoru je
pak [email protected]/resource.
V rámci této analýzy bude zohledňován zejména pohled ze strany klientské aplikace.
3.1.2
Standardizace a XEPy
Jednotlivé standardy jsou definovány IETF v RFC dokumentech. Nejdůležitějšı́ pro IM komunikaci jsou:
1
eXtensible Markup Language
KAPITOLA 3. ANALÝZA A NÁVRH ŘEŠENÍ
7
• RFC 3290 – ”XMPP: Core”[5]
• RFC 3291 – ”XMPP: Instant Messaging and Presence”[6]
XMPP je navrženo tak, aby bylo velmi dobře rozšiřitelné, a proto také vzniklo mnoho
rozšı́řenı́ protokolu, která definujı́ chovánı́ entit v sı́ti pro různá použitı́. Tato rozšı́řenı́ jsou standardizována v dokumentech zvaných XEP (XMPP Extension Protocol). Tyto dokumenty jsou
souhrnně uloženy na stránkách xmpp.org, spravovaných XSF (XMPP Software Foundation).
Tam je mohou prohlı́žet a komentovat ostatnı́ vývojáři. Dokumenty XEP se nacházejı́ v různých
stavech; dokončená a schválená rozšı́řenı́ pak zı́skávajı́ stav final, který zaručuje, že je dokumentace kompletnı́ a standardizovaná.
XEP dokumenty jsou čı́slovány ve formátu XEP-0000 a existuje pět typů: standards track,
informational, historical, humorous a procedural. Nejdůležitějšı́m pro implementaci software je
typ standards track, který definuje bud’ protokol na úrovni sı́t’ové komunikace (tedy popisuje
samotné rozšı́řenı́ základnı́ho XMPP) nebo specifikuje tzv. conformace requirements (to jsou
podmı́nky, které musı́ server/klient splnit, aby mohl prohlašovat, že je vyhovujı́cı́ podle daných
požadavků).
3.1.3
Protokol
XMPP je původně založeno na TCP/IP sı́tı́ch. Vzhledem k jeho verzatilitě ale nenı́ problém
jej použı́t i nad jinými technologiemi – resp. na jiné sı́t’ové vrstvě, jmenovitě napřı́klad nad
HTTP za využitı́ polling mechanismů2 . Také existuje návrh standardu pro použitı́ XMPP nad
technologiı́ WebSockets, která bude umožňovat vı́ce oboustranných, plně duplexnı́ch kanálů pro
komunikaci přes jediný TCP socket.
Výchozı́ port, použı́vaný v TCP/IP pro připojenı́ klient-server je 5222, při spojenı́ typu
server-server se použı́vá 5269.
Strukturně je komunikace pomocı́ XMPP jeden dlouhý XML dokument. To svým způsobem
ztěžuje implementaci, protože je nutné za běhu načı́tat tzv. ”nekonečné XML”, zároveň je ale
možné komunikaci pomocı́ XML jednoduše validovat. Povinné kódovánı́ je UTF-8.
Na začátku každé komunikace je nutné otevřı́t XML dokument a založit kořenový element.
Typicky vypadajı́ prvnı́ data, poslaná klientem takto:
<?xml version="1.0" encoding="UTF-8"?>
<stream:stream
xmlns="jabber:client"
2
polling nad HTTP se věnuje XEP-0206 – XMPP over BOSH
8
KAPITOLA 3. ANALÝZA A NÁVRH ŘEŠENÍ
xmlns:stream="http://etherx.jabber.org/streams"
version="1.0"
to="server.tld">
Po úspěšné inicializaci stream elementu, posı́lajı́ jednotlivé entity skrze tento vytvořený kanál
neohraničený počet zpráv, které se v terminologii XMPP nazývajı́ souhrnně stanza. V RFC jsou
definovány tři typy zpráv, které je možné poslat v XMPP kanálu:
• <message />
• <presence />
• <iq />
Standardnı́ komunikace ve vytvořeném kanále vypadá tedy ve zjednodušenı́ následovně [5]:
|--------------------|
| <stream>
|
|--------------------|
| <presence>
|
|
|
<show/>
| </presence>
|
|--------------------|
| <message to=’foo’> |
|
<body/>
| </message>
|
|
|--------------------|
| <iq to=’bar’>
|
|
|
<query/>
| </iq>
|
|--------------------|
| ...
|
|--------------------|
| </stream>
|
|--------------------|
Je důležité zmı́nit, že zprávy mezi klienty v sı́ti XMPP vždy doručuje server a při komunikaci
nevzniká žádný kanál, který by přı́mo propojoval dvě klientské entity. To je dobré zejména
z toho důvodu, že server umı́ lépe směrovat dané zprávy a zajišt’uje také předávánı́ na jiné
servery, přı́padně gatewaye pro propojenı́ s jinými komunikačnı́mi systémy.
KAPITOLA 3. ANALÝZA A NÁVRH ŘEŠENÍ
3.1.4
9
IM komunikace a online stavy
Jak bylo zmı́něno výše, během bezchybné komunikace můžou být využity pouze tři definované
elementy, nazývané stanzy. Veškerá dalšı́ rozšı́řenı́ protokolu jsou pak zapouzdřena do těchto
základnı́ch stanz.
3.1.4.1
Message stanza
<message /> stanza je základnı́m stavebnı́m kamenem protokolu. Jde o zprávu, která se předá
serveru a obvykle nenı́ vyžadováno potvrzenı́. Tento komunikačnı́ typ je určen k rychlému
předávánı́ zpráv. Je definováno pět typů zpráv podle důvodu jejich vzniku:
• normal – zpráva podobná e-mailu, kdy se neočekává okamžitá odpověd’
• chat – zpráva využı́vaná pro IM, kdy se očekává rychlá výměna zpráv mezi dvěma entitami
• groupchat – zpráva, která je využita pro komunikaci mezi vı́ce uživateli najednou, typicky
velmi podobné mı́stnosti v IRC
• headline – typ zprávy využitý k informovánı́ druhé strany, kdy odpověd’ nenı́ očekávána
vůbec
• error – zpráva popisujı́cı́ chybu vzniklou v důsledku přijetı́ předchozı́ zprávy
Typická zpráva, která procházı́ sı́tı́ v přı́padě uvažované IM komunikace, může vypadat
napřı́klad takto:
<message from=’[email protected]’
to=’[email protected]’
type=’chat’
xml:lang=’en’>
<body>Art thou not Romeo, and a Montague?</body>
<delay xmlns="urn:xmpp:delay" stamp="2010-11-07T18:42:03Z"/>
</message>
Většina rozšı́řenı́ protokolu XMPP pracuje právě s tı́mto typem stanzy a do těla elementu
<message /> vkládá dalšı́ elementy, které se ve většině přı́padů identifikujı́ svou namespace.
Jako přı́klad lze ve výše uvedené ukázkové zprávě najı́t element <delay />, který byl vložen
podle XEP-0203 Delayed Delivery, a který určuje zpožděnı́, resp. reálný čas odeslánı́ zprávy.
10
KAPITOLA 3. ANALÝZA A NÁVRH ŘEŠENÍ
3.1.4.2
Presence stanza
Jednou ze základnı́ch vlastnostı́ IM sı́tı́ je určovánı́, zda je druhá entita přı́stupná k sı́t’ové
komunikaci či nikoliv. K tomuto sloužı́ v XMPP stanza <presence />, pomocı́ které entita
informuje server o svém stavu.
Protože taková informace nenı́ vždy považována jako veřejná, existuje v XMPP autorizačnı́
schéma, kterým každý daný klient určuje, kdo může jeho stav v sı́ti vidět a kdo nikoliv. V XMPP
terminologii je toto schéma pojmenováno jako presence subscription, v češtině se použı́vá termı́n
autorizace. V tomto schématu jsou definovány čtyři stavy – none, from, to, both. Popisujı́ stavy,
kdy nenı́ mezi dvěma entitami žádná autorizace, existuje autorizace jednosměrná nebo jsou
entity vzájemně autorizované.
Autorizace je uložena u seznamu kontaktů, který se nazývá roster. Jde vlastně o seznam
všech kontaktů spojený s jejich Jabber ID, většinou také zobrazujı́cı́ presence a subscription.
Tento seznam je uložen na serveru a každý klient má svůj vlastnı́, se kterým může operovat.
V presence stanze může být uložen i tzv. status klienta, což je krátká textová informace,
rozšiřujı́cı́ jeden z definovaných presence stavů. Tyto stavy jsou definovány v RFC a odpovı́dajı́
již historicky zavedeným stavům pro IM komunikaci, které jsou stejné i ve většině jiných IM
systémů.
• on – Entita je on-line
• away – Entita je dočasně pryč
• chat – Entita je k dispozici pro komunikaci
• xa – Entita je pryč na delšı́ dobu
• dnd – Entita nechce být rušena
• off – Entita je off-line
Presence stanza může vypadat napřı́klad takto:
<presence xml:lang=’en’>
<show>dnd</show>
<status>Wooing Juliet</status>
</presence>
KAPITOLA 3. ANALÝZA A NÁVRH ŘEŠENÍ
3.1.4.3
11
IQ stanza
<iq /> (z anglického Info/Query) stanza umožňuje využı́t strukturované komunikace typu
požadavek – odpověd’. Užitı́ je podobné jako napřı́klad v HTTP protokolu použitı́ GET, POST
a PUT. Existujı́ 4 typy IQ stanz:
• get – odesı́latel požaduje nějaké informace či provedenı́ nějaké akce. Tento typ zprávy je
podobný HTTP GET.
• set – odesı́latel poskytuje informace, přı́padně žádá o provedenı́ nějaké akce. Tento typ
zprávy je podobný HTTP POST nebo PUT.
• result – odesı́latel odpovı́dá na get zprávu odeslánı́m požadovaných informacı́ nebo
potvrzuje provedenı́ akce žádané pomocı́ set.
• error – odesı́latel upozorňuje protistranu o chybě při zpracovánı́ předchozı́ho požadavku.
To může být způsobeno chybou oprávněnı́, chybou systému, atd.
Obrázek 3.1: Přı́klad komunikace pomocı́ IQ stanz
3.1.5
Vyjednánı́ spojenı́ a jeho bezpečnost
Existuje několik možnostı́ jak zabezpečit XMPP stream. RFC definuje, že obě entity musı́
použı́t SASL autentifikaci a měly by použı́t i TLS šifrovánı́ kanálu. Mimo TLS je možné ještě
použı́t SSL anebo posı́lat komunikaci nezašifrovanou. Poslednı́ z možnostı́ je nejméně náročná
12
KAPITOLA 3. ANALÝZA A NÁVRH ŘEŠENÍ
na použitý hardware, je ale zároveň nejméně bezpečná, protože je možné zası́lané zprávy na
sı́ti odposlechnout.
K zajištěnı́ autenticity obou stran komunikace se použı́vá profil SASL, specifická revize pro
XMPP. SASL je zkratkou pro Simple Authentication and Security Layer a definuje způsob,
jakým účastnı́ci komunikace sestavujı́ spojenı́ tak, aby bylo důvěryhodné.
3.1.5.1
Průběh SASL
Po úspěšném otevřenı́ streamu musı́ server odeslat seznam povolených mechanismů autentifikace. Společně s tı́mto seznamem posı́lá i informaci zda podporuje – přı́padně vyžaduje –
použitı́ TLS během následujı́cı́ho spojenı́. Pokud je TLS požadováno, zahájı́ se komunikace na
socketu pomocı́ TLS.
Po zı́skánı́ seznamu podporovaných mechanismů, přı́padně po přepnutı́ socketu na TLS,
klient vybı́rá, který autentifikačnı́ mechanismus vybere. V současné době jsou nejpoužı́vanějšı́mi
(rozhodně ale ne jedinými) mechanismy:
• DIGEST-MD5
• PLAIN
Při neúspěšné autentifikaci server obvykle ukončuje spojenı́. Po úspěšné autentifikaci druhé
strany se otevı́rá nový stream, který již může být považován za ověřený. Dalšı́m krokem k
úspěšnému sestavenı́ spojenı́ je tzv. bind, kdy klient žádá server o přiřazenı́ Jabber ID k danému
resource. Pokud proběhne tento krok v pořádku, může klient požádat o vytvořenı́ Jabber session
(nenı́ vždy nutné). Poté je spojenı́ kompletnı́ a může se přistoupit k posı́lánı́ XMPP stanz.
V přı́padě, že se některá ze stran komunikace pokusı́ o zaslánı́ dat ještě před sestavenı́m ověřené komunikace, kanál musı́ být serverem uzavřen a je oznámena chyba
<not-authorized/>.
Celý proces sestavovánı́ komunikace je dobře popsaný grafem na obrázku A.1 v přı́loze.
3.1.5.2
PLAIN autentifikace
PLAIN autentifikace je nejjednoduššı́ způsob, jak provést ověřenı́ uživatele. Klient zası́lá JID,
uživatelské jméno a heslo v nezašifrované podobě, pouze zakódované jako base64 ve formátu
username@server<0>username<0>secret.
KAPITOLA 3. ANALÝZA A NÁVRH ŘEŠENÍ
13
Zaslaná data můžou vypadat jako3 :
<auth xmlns="urn:ietf:params:xml:ns:xmpp-sasl" mechanism="PLAIN">
aG2udmFicnVjZWt3AZ11haWruY29rA2hv3nphYfJ3D2VrAG9mZnF3bTk4MQ==
</auth>
Server odpovı́dá na daný token elementy <success /> nebo <failure /> a v přı́padě chyby
uzavı́rá spojenı́.
3.1.5.3
DIGEST-MD5 autentifikace
DIGEST-MD5 je založena na ověřovánı́ stylem challenge – response. To znamená, že klientská strana nikdy neposı́lá ověřovacı́ data bez vyžádánı́ serverem. To jednoznačně přispı́vá k
bezpečnosti celého způsobu ověřovánı́.
Pokud tedy zvolı́ klient jako mechanismus DIGEST-MD5, musı́ čekat, než si server vyžádá
autorizačnı́ údaje zaslánı́m <challenge /> zprávy, tedy výzvy k ověřenı́. V této výzvě jsou
pomocı́ base64 zakódována data, která klient musı́ přečı́st a na jejich základě vytvořit odpověd’,
která potvrdı́, že tento klient zná heslo k danému uživatelskému jménu.
<auth xmlns=’urn:ietf:params:xml:ns:xmpp-sasl’ mechanism=’DIGEST-MD5’/>
Server odpovı́ výzvou, která obsahuje řetězec s páry atribut-hodnota oddělenými čárkou,
napřı́klad:
<challenge xmlns=’urn:ietf:params:xml:ns:xmpp-sasl’>
cmVhbG09ImNoYXQuZmFjZWJvb2suY29tIixub25jZT0iOEZFRUJDMzk4RD
c1RTFFQUMwOTRENkNEQzkzRDE3MzgiLHFvcD0iYXV0aCIsY2hhcnNldD11
dGYtOCxhbGdvcml0aG09bWQ1LXNlc3M=
</challenge>
dekódováno jako:
realm="chat.facebook.com",nonce="8FEEBC398D75E1EAC094D6CDC93D1738",
qop="auth",charset=utf-8,algorithm=md5-sess
3
při použitı́ SASL nenı́ dovoleno posı́lat tzv. whitespace znaky; zde jsou použity pouze pro zpřehledněnı́
ukázky
14
KAPITOLA 3. ANALÝZA A NÁVRH ŘEŠENÍ
Na základě zı́skaných údajů může klient sestavit odpověd’. Jak napovı́dá název autentifikace,
využı́vá hashovacı́ algoritmus MD5. Klient přeposı́lá většinu hodnot původnı́ výzvy, přidává ale
zejména atributy username a response, kterými dokazuje znalost hesla. Výhodou je, že heslo z
response nelze zpětně zı́skat.
Response se sestavuje takto:
1. Sestavı́ se řetězec username:realm:password, který nazveme A
2. Vypočı́tá se 16-oktetový MD5 hash z řetězce A, který označı́me B
3. Vytvořı́ se řetězec B:nonce:cnonce:authzid, který nazveme A1
4. Vytvořı́ se řetězec AUTHENTICATE:digest-uri, který nazveme A2
5. A1 a A2 se zahashujı́ pomocı́ MD5 jako hexadecimálnı́ řetězce a výsledky nazveme H1 a
H2
6. Řetězec H1:nonce:nc:cnonce:qop:H2 se zahashuje pomocı́ MD5 a jeho 32B hexadecimálnı́ výsledek je hodnotou response
Výsledný řetězec, který klient vracı́ serveru, může vypadat napřı́klad takto:
username="user1",realm="chat.facebook.com",nonce="8FEEBC398D75E1EAC094",
cnonce="8FEEBC398D75E1EAC094",nc=00000001,qop=auth,digest-uri="xmpp/localhost",
response=3b395a5824d41a1bd0228a709e8fd78e,charset=utf-8
A konečný element poslaný do XMPP kanálu tedy bude:
<response xmlns="urn:ietf:params:xml:ns:xmpp-sasl">
dXNlcm5hbWU9InVzZXIxIixyZWFsbT0iY2hhdC5mYWNlYm9vay5jb20iLG
5vbmNlPSI4RkVFQkMzOThENzVFMUVBQzA5NCIsY25vbmNlPSI4RkVFQkMz
OThENzVFMUVBQzA5NCIsbmM9MDAwMDAwMDEscW9wPWF1dGgsZGlnZXN0LX
VyaT0ieG1wcC9sb2NhbGhvc3QiLHJlc3BvbnNlPTNiMzk1YTU4MjRkNDFh
MWJkMDIyOGE3MDllOGZkNzhlLGNoYXJzZXQ9dXRmLTg=
</response>
Před samotným dokončenı́m autorizačnı́ho mechanismu posı́lá server ještě jednu
<challenge />, na kterou klient odpovı́dá prázdným <response /> elementem. Poté
je úspěch potvrzen přijetı́m <success /> elementu. V přı́padě chyby je vrácen element
<failure /> a spojenı́ je ukončeno4 .
4
V tomto popisu nejsou uvedeny namespace jednotlivých elementů, které musı́ byt v reálné komunikaci
přı́tomny
KAPITOLA 3. ANALÝZA A NÁVRH ŘEŠENÍ
3.2
15
Mozilla Application Framework
Mozilla Application Framework (původně také označovaný jako XPFE, tj. Cross Platform Front
End) je rodina multiplatformnı́ch frameworků (resp. komponent), ze kterých se skládajı́ Mozilla
aplikace.
3.2.1
JavaScript
Většina kódu Mozilla aplikacı́ je napsána v JavaScriptu. JavaScript je dynamicky typovaný,
objektově orientovaný skriptovacı́ jazyk, jeho přı́stup k objektům je ale od klasických jazyků
typu Java odlišný – použı́vá totiž prototypovánı́.
V jazycı́ch založených na prototypech existujı́ dva způsoby, jak vytvořit objekt (narozdı́l od
jediné možnosti u klasických class-based jazyků, kde je vždy použit konstruktor). Objekt může
být vytvořen takzvaně ex nihilo (latinsky z ničeho) nebo pomocı́ klonovánı́ existujı́cı́ho objektu
(resp. jeho prototypu). Klonovánı́m pak vzniká objekt, který je stejný jako zdrojový. I když
takovýto model nepoužı́vá přı́mo dědičnost tak, jak je použita v klasických class-based jazycı́ch,
je možné tento přı́stup dobře simulovat (i když ne vždy je to vhodné).
JavaScript je velmi vyspělý jazyk a mezi dalšı́ zajı́mavé vlastnosti patřı́ anonymnı́ funkce,
vnořené funkce, uzávěry, funkce s proměnným počtem argumentů a dalšı́.
3.2.2
Komponenty frameworku
Mezi nejdůležitějšı́ komponenty Mozilla Application Frameworku patřı́ bezesporu Gecko neboli
layout engine, podporujı́cı́ HTML, CSS, JavaScript, XUL a dalšı́. Tento vykreslovacı́ engine je
základem většiny Mozilla aplikacı́, z nichž jistě nejznámějšı́ je Mozilla Firefox.
Komponentou, použitou pro uživatelské rozhranı́ v Mozilla Application Frameworku, je XUL.
XUL je zkratka pro XML User Interface Language a jde o jazyk založený na XML popisujı́cı́
uživatelské rozhranı́. Zahrnuje podporu pro CSS a JavaScript a je závislé na vykreslovacı́m
engine Gecko. Definuje obecně velké množstvı́ ovládacı́ch prvků, které se mohou na jiných
platformách vykreslovat různě a přitom mı́t stejnou definici v XUL.
S XUL souvisı́ i jazyk XBL, který umožňuje definovat vlastnı́ ovládacı́ prvky, které budou
použity v XUL.
Dalšı́ důležitou částı́ Mozilla Aplication Frameworku je Necko. Jedná se o knihovnu poskytujı́cı́ API pro podporu sı́t’ových aplikacı́ pracujı́cı́ na různých vrstvách OSI modelu.
XPCOM je komponentový model, pomocı́ něhož Mozilla Application Framework poskytuje
16
KAPITOLA 3. ANALÝZA A NÁVRH ŘEŠENÍ
multiplatformnı́ správu komponent, abstrakci souborů, předávánı́ objektů a správu paměti
[8]. Umožňuje využı́t téměř všechny vlastnosti ostatnı́ch částı́ frameworku využı́t ze skriptů
jakékoliv Mozilla aplikace.
Komponenty XPCOM mohou být mimo C++ implementovány i v JavaScriptu, Javě nebo
Pythonu. XPCOM použı́vá dialekt IDL (Interface Definition Language), nazývaný XPIDL.
XPCOM samo o sobě nabı́zı́ základnı́ komponenty jako správu paměti, základnı́ datové
struktury (řetězce, pole a dalšı́). Většina komponent ale pocházı́ z jiných částı́ frameworku,
zejména z komponent Gecko a Necko.
XPConnect je technologie, která propojuje JavaScript na úrovni interface a XPCOM komponenty v rámci Mozilla aplikace, jak ukazuje obrázek 3.2.
Obrázek 3.2: Mozilla Application Framework – XPConnect, zdroj: [3]
XPInstall je technologie, která umožňuje uživatelům i vývojářům Mozilla aplikace jednoduše
instalovat, rozšiřovat či aktualizovat. Balı́k, ve kterém je software distribuován, je nazýván
XPI (Cross Platform Installation archive) a je to ZIP soubor obsahujı́cı́ soubory v definované
struktuře (vı́ce v kapitole 3.2.3.2).
KAPITOLA 3. ANALÝZA A NÁVRH ŘEŠENÍ
17
Obrázek 3.3: Instalace XPI balı́ku do Mozilla aplikace
3.2.3
Vytvářenı́ rozšı́řenı́ Mozilla aplikace
Tato kapitola práce se bude zabývat tı́m, jak lze vytvořit add-on (resp. rozšı́řenı́) pro Mozilla
aplikaci, konkrétně Mozilla Thunderbird.
Sada souborů XUL, JavaScript, CSS a jiných se souhrnně nazývá balı́k (package). Do Mozilla aplikacı́ je možné tyto balı́ky instalovat pomocı́ XPInstall a jejich obsah referencovat pomocı́ Chrome URL. Instalovatelný balı́k se musı́ řı́dit pravidly, která definujı́, jakou má takové
rozšı́řenı́ mı́t strukturu, aby bylo do aplikace instalovatelné.
Balı́k může obsahovat mimo rozšı́řenı́ aplikace i definic změny vzhledu, přı́padně vı́ce rozšı́řenı́
najednou. Dále v této práci budou popsány hlavnı́ vlastnosti balı́ku obsahujı́cı́ho pouze jedno
rozšı́řenı́ Mozilla aplikace.
3.2.3.1
Chrome URL
Výraz chrome má v Mozilla Application Frameworku vı́ce významů; v této práci bude ale
převládat ten, který popisuje chrome:// URL. Taková URL se využı́vá v Mozilla aplikacı́ch
k definici mı́sta, kde se nacházı́ určitý soubor. Zapisujı́ se podobně jako dobře známé HTTP
URL, ale referencujı́ soubory, které jsou registrované v tzv. chrome registry. To umožňuje mı́t
soubory fyzicky umı́stěné kdekoliv a přitom je referencovat vždy stejným chrome URL.
Typická chrome URL vypadá má formát chrome://<package name>/<part>/<file.xul>,
kde <package name> je název balı́ku, <part> je název jeho části (může být content, skin nebo
locale) a poslednı́ částı́ je přı́mo jméno soubor (case-insensitive).
18
KAPITOLA 3. ANALÝZA A NÁVRH ŘEŠENÍ
3.2.3.2
Chrome manifest a struktura add-onu
Chrome manifest popisuje daný balı́k a mapuje fyzické umı́stěnı́ souboru na Chrome URL.
Navı́c definuje jednotlivým adresářům, resp. souborům, jak s nimi má aplikace zacházet, tedy
jestli se jedná o spustitelný obsah, definici vzhledu, lokalizaci a podobně. Také je možné pomocı́
direktivy overlay slučovat soubory se soubory z jiných balı́ků. Tato funkčnost je velmi důležitá,
protože umožňuje sloučit existujı́cı́ uživatelské rozhranı́ s nově přidaným.
content addon.chrome chrome/content/
skin addon.chrome classic chrome/skin/classic/
overlay chrome://messenger/content/messenger.xul \\
chrome://addon.chrome/content/myOwnOverlay.xul
Instalovatelný balı́k musı́ také dodržovat předepsanou strukturu souborů, aby byl funkčnı́.
Důležitý je RDF soubor, který definuje mimo jiné jméno, verzi, identifikaci balı́ku a zacı́lenou
Mozilla aplikaci (resp. aplikace). Typické rozšı́řenı́ pro Mozilla aplikaci může mı́t strukturu,
která je uvedena v tabulce 3.1.
/install.rdf
Instalačnı́ manifest s popisem balı́ku
/chrome.manifest
Chrome manifest
/chrome/content/*
Hlavnı́ obsah balı́ku
/chrome/skin/*
Definice vzhledu UI
/defaults/preferences/*.js
Výchozı́ nastavenı́ preferences
Tabulka 3.1: Struktura instalovatelného balı́ku rozšı́řenı́
KAPITOLA 3. ANALÝZA A NÁVRH ŘEŠENÍ
3.3
19
ExtBrain Communicator
V této práci bude navržena a implementována knihovna pro komunikaci v XMPP tak, aby
byla optimalizována pro Mozilla Application Framework a zejména tak, aby poskytovala dobře
použitelné rozhranı́ pro přı́stup ke XMPP kanálu, které bude přı́stupné jiným částem projektu
ExtBrain.
Dalšı́ částı́ bude implementace klienta, který umožnı́ komunikovat přes XMPP a pracovat s
adresáři poštovnı́ho klienta Thunderbird. Jak již bylo řečeno, rozšı́řenı́, které vznikne v rámci
této práce, vznikne částečně z již existujı́cho ExtBrain Communicatoru. Tento nefunguje v
nové verzi Mozilla Thunderbid, přesto práce bude vycházet z již zavedených konceptů grafického rozhranı́; bude ale přidávat nové vlastnosti, které ve staršı́ verzi Thunderbirdu nebyly
k dispozici.
3.3.1
XMPP knihovna
Knihovna bude potřebovat přı́mý přı́stup k socketu, jenž bude zprostředkován JavaScriptu
XPCOM komponentou frameworku Necko.
Obrázek 3.4: Návrh třı́dy XMPPSocket
Protože se XMPPSocket bude zabývat pouze připojenı́m ke XMPP serveru, bude objekt naslouchajı́cı́ přı́chozı́m datům na socketu data rovnou převádět na DOM reprezentaci daného
XML, které bude předáváno dále.
20
KAPITOLA 3. ANALÝZA A NÁVRH ŘEŠENÍ
Přı́chozı́ XML bude analyzováno komponentou nsIDOMParser, která vracı́ přı́slušnou reprezentaci v DOM.
DOM, který bude výstupem z objektu XMPPSocket (obrázek 3.4), bude předáván třı́dě objektu XMPP (obrázek 3.5). Ten bude zastřešovat veškerou základnı́ komunikaci s XMPP serverem.
Bude implementovat:
• Otevřenı́ spojenı́ a jeho zabezpečenı́
• Autentifikaci vůči serveru (podpora PLAIN a DIGEST-MD5 metod)
• Binding JID
• Otevřenı́ jabber session
• Odesı́lánı́ dat
• Přijı́mánı́ dat a vznik událostı́ na jejich základě
• Řádné ukončenı́ spojenı́
Obrázek 3.5: Návrh třı́dy XMPP
Zpracovánı́ událostı́ vzniklých při přı́jmu dat bude řešit objekt, který si zaregistruje daný
listener. V tomto přı́padě to bude objekt Jabber (obrázek 3.6), který bude tvořit most mezi
událostmi přijatými z grafického rozhranı́ a z XMPP kanálu.
Diagram třı́d je k nahlédnutı́ na obrázku A.3 v přı́loze.
KAPITOLA 3. ANALÝZA A NÁVRH ŘEŠENÍ
21
Obrázek 3.6: Návrh třı́dy Jabber
3.3.2
Řešenı́ vı́ce souběžných XMPP spojenı́
Jelikož mezi požadavky na vyvı́jený add-on je možnost spuštěnı́ vı́ce spojenı́ najedou, bude
implementován kontejner, ve kterém budou uložena spojenı́ (resp. objekty Jabber), S těmi
bude možné hromadně nebo jednotlivě manipulovat.
Každý klient s platným XMPP spojenı́m musı́ mı́t unikátnı́ Jabber ID, bude možné jednotlivá
spojenı́ podle Jabber ID identifikovat. Bude implementován objekt, který bude informace o JID
shromažd’ovat.
Obrázek 3.7: Návrh třı́dy Connections
22
KAPITOLA 3. ANALÝZA A NÁVRH ŘEŠENÍ
3.3.3
Kontakty z adresářů a z rosteru
Každý XMPP účet má na serveru definován svůj vlastnı́ roster, tedy seznam všech kontaktů. V
běžných klientech se po spojenı́ se serverem tento roster zobrazı́ jako seznam kontaktů současně
s informacı́ o online dostupnosti daného kontaktu.
Mozilla Thunderbird má svůj vlastnı́ systém adresářů, ve kterých ukládá kontaktnı́ informace,
a protože se jedná o poštovnı́ klient, jde zejména o e-mailové adresy. Adresářů může být v
Thunderbirdu vı́ce než jeden, vyhledávat lze ale vždy jen v jednom vybraném. Proto bude
ExtBrain Communicator rozšı́řenı́ zobrazovat sloučeně kontakty ze všech v nastavenı́ vybraných
adresářů a z rosterů všech připojených účtů a umožňovat v nich efektivně vyhledávat.
Bude nutné implementovat třı́du Contact, která bude schopna zobrazovat informace ze svého
rodičovského adresáře, a zároveň se slučovat s kontakty v rosteru podle Jabber ID. Bude upraven
formulář na úpravu (resp. přidánı́) kontaktu a v něm bude zpřı́stupněna možnost definovat
omezený počet Jabber ID, se kterými se tento kontakt sloučı́.
Obrázek 3.8: Návrh třı́dy Contact
KAPITOLA 3. ANALÝZA A NÁVRH ŘEŠENÍ
3.3.4
23
Uživatelské rozhranı́
Uživatelské rozhranı́ bude vycházet z původnı́ho prototypu ExtBrain Communicatoru, tedy v
levém dolnı́m rohu aplikace bude umı́stěn seznam kontaktů společně s dalšı́mi ovládacı́mi prvky
spojenı́. Návrh vzhledu je na obrázku 3.9.
Obrázek 3.9: Uživatelské rozhranı́ hlavnı́ho okna
Po přı́chodu nové zprávy nebo po uživatelově žádosti se otevře konverzačnı́ okno v
nové záložce poštovnı́ho klienta (obrázek 3.10), kde budou jednotlivé konverzace odděleny
systémovými záložkami. Oknu bude dominovat textové pole s konverzacı́, bude zobrazovat
informace o přı́jemci a bude umožňovat také výběr Jabber ID odesı́latele i přı́jemce.
24
KAPITOLA 3. ANALÝZA A NÁVRH ŘEŠENÍ
Obrázek 3.10: Uživatelské rozhranı́ záložky s konverzacı́
K nastavenı́ účtů bude vytvořen formulář (obrázek 3.11), který bude umı́stěn do hlavnı́
nabı́dky Tools aplikace. Po vyvolánı́ se zobrazı́ okno, které bude umožňovat úpravu, mazánı́ a
zakládánı́ jednotlivých jabber účtů. Zároveň také bude k dispozici seznam dostupných adresářů,
které se budou použı́vat k zobrazenı́ v seznamu kontaktů tohoto rozšı́řenı́.
Obrázek 3.11: Uživatelské rozhranı́ nastavenı́
KAPITOLA 3. ANALÝZA A NÁVRH ŘEŠENÍ
3.4
25
Vývojové prostředı́ a použité nástroje
Vývoj rozšı́řenı́ proběhne za pomoci integrovaného vývojového prostředı́ (IVP, resp. IDE5 )
NetBeans 6.9.1 [10] a jeho plug-inu foxbeans [12]. Ten umožňuje jednoduše konfigurovat,
vyvı́jet a sestavovat projekt jako rozšı́řenı́ pro Mozilla aplikace.
• Pro testovánı́ knihovny pro práci s XMPP byl použit open-source jabber server ejabberd
verze 2.1.5 [4].
• Pro debugovánı́ na sı́t’ové úrovni byl použit Network Protocol Analyzer Wireshark verze
1.4.1 [13].
• Pro vývoj a testovánı́ v rámci Thunderbirdu byl použit JavaScript Debugger Venkman,
klient pro SQLite databáze SQLite Manager a prohlı́žeč aktivnı́ho DOM DOM Inspector.
• Pro laděnı́ vzhledu aplikace byl použit XUL designer XULExplorer verze 1.0a1, který
umožňuje zadané XUL okamžitě prohlı́žet.
• Pro průběžné testovánı́ klientem na druhé straně spojenı́ byl použit Mac OS X klient
Adium verze 1.4.1 [1].
• Pro verzovánı́ byl použit nejdřı́ve systém SubVersion, poté byl projekt převeden na Mercurial, výchozı́ VCS6 Mozilla aplikacı́.
5
6
Integrated Development Envrironment
Version Control System
26
KAPITOLA 4. REALIZACE
4 Realizace
V této kapitole budou popsány méně standardnı́ části implementace společně s problémy, které
při vývoji vyvstaly.
4.1
4.1.1
Knihovna XMPP
Socket
Implementace XMPP knihovny použı́vá XPCOM komponenty Mozilla Application Frameworku. K zı́skánı́ přı́stupu k socketu je použita komponenta nsIProtocolProxyService,
která poskytuje přı́stup k fyzickému socketu pomocı́ streamů.
Pro přı́chozı́ data je použit řetěz komponent (resp. jejich rozhranı́) nsIInputStreamPump,
nsIScriptableInputStream a nsIScriptableUnicodeConverter. Ten umožňuje čı́st textová
data ze socketu převedená přı́mo do požadovaného kódovánı́ (dle RFC dokumentu je to UTF8). Zápis do socketu je prováděn přı́mo pomocı́ interface nsIConverterOutputStream, který
data konvertuje do zvoleného kódovánı́.
Je použito asynchronnı́ čtenı́ ze socketu. Objekt, který zpracovává data, musı́ implementovat
nsISimpleStreamListener, tedy metody:
• onStartRequest
• onStopRequest
• onDataAvailable
Třı́da Socket tyto metody implementuje, takže asynchronnı́ volánı́ jsou zpracovávána přı́mo
v nı́.
this._inputPump = Cc[’@mozilla.org/network/input-stream-pump;1’]
.createInstance(Ci.nsIInputStreamPump);
this._inputStream = this._transport.openInputStream(0,0,0);
this._inputPump.init(this._inputStream, -1, -1, 0, 0, false);
this._inputPump.asyncRead(this, null);
this._outputStream = this._transport.openOutputStream(0,0,0);
this._output = Cc[’@mozilla.org/intl/converter-output-stream;1’]
KAPITOLA 4. REALIZACE
27
.createInstance(Ci.nsIConverterOutputStream);
this._output.init(this._outputStream, ’UTF-8’, 0, ’?’.charCodeAt(0));
4.1.2
4.1.2.1
Analýza XML
Parser
Jak bylo uvedeno dřı́ve, třı́da Socket zpracovává také přijaté XML a vytvářı́ jeho reprezentaci v DOM, kterou předává dalšı́m komponentám ke zpracovánı́. Jako parser byla použita
komponenta DOMParser.
Nevýhodou DOMParseru je, že při chybě nepracuje s výjimkami, ale vracı́ chybu, která
nenı́ zachytitelná klasickou try – catch konstrukcı́. Metodou parseFromString je tedy možné
zpracovat pouze validnı́ XML a nenı́ možné jednoduchým způsobem zjistit, zda byla operace
provedena úspěšně či nikoliv.
Protože je XMPP stream takzvaně nekonečné XML a často použı́vá namespace, nejsou části
přijaté na straně socketu validnı́m XML. Při sestavovánı́ spojenı́ může dojı́t napřı́klad k přijetı́
následujı́cı́ posloupnosti paketů:
#1: <?xml version="1.0"?>
<stream:stream xmlns="jabber:client"
xmlns:stream="http://etherx.jabber.org/streams"
version="1.0" to="localhost">
#2: <stream:features xmlns:stream="http://etherx.jabber.org/streams">
<mechanisms xmlns="urn:ietf:params:xml:ns:xmpp-sasl">
<mechanism>PLAIN</mechanism>
<mechanism>DIGEST-MD5</mechanism>
</mechanisms>
</stream:features>
#3: <success xmlns="urn:ietf:params:xml:ns:xmpp-sasl"/>
Z uvedených přı́kladů můžou být DOMParserem jako validnı́ vyhodnocena pouze data čı́slo
3. Prvnı́ přijatý text nenı́ platným XML, protože element <stream:stream /> nenı́ platně
uzavřen (což je ale základnı́ vlastnostı́ neskončené komunikace pomocı́ XMPP). Druhý přijatý
text také nenı́ platný, protože element s lokálnı́m názvem <features /> nemá nad sebou
obalový element <stream />.
28
KAPITOLA 4. REALIZACE
Problém je v kódu vyřešen tak, že se kontroluje, zda jde o začátek XMPP streamu, a následně
je pak každý přijatý element zabalen do elementu <stream:stream />. To způsobı́, že veškeré
elementy přijaté v kanálu jsou platným XML. Následuje přı́klad zpracovaného elementu čı́slo
2, který je již platným XML.
<stream:stream xmlns="jabber:client" version="1.0" xml:lang="en"
xmlns:stream="http://etherx.jabber.org/streams">
<stream:features xmlns:stream="http://etherx.jabber.org/streams">
<mechanisms xmlns="urn:ietf:params:xml:ns:xmpp-sasl">
<mechanism>PLAIN</mechanism>
<mechanism>DIGEST-MD5</mechanism>
</mechanisms>
</stream:features>
</stream:stream>
4.1.2.2
Fragmentace
Dalšı́m problémem při zpracovánı́ dat přijatých v Socketu je fragmentace přı́chozı́ho XML. Ta
se projevuje zejména při přijı́mánı́ většı́ho objemu dat, zejména při přı́jmu binárnı́ch dat (v
kanále XMPP kódovaných pomocı́ base64) jako jsou napřı́klad avatary uživatelů.
Pro tento přı́pad je implementována funkce, která kontroluje, zda jsou XML data řádně
zakončená.
#1: <message from="jid@server" to="jid2@server">
<event xmlns="http://jabber.org/protocol/pubsub#event">
<items node="urn:xmpp:avatar:data">
<item id="96dd92efb8c9cbbd62100add0dacbd62b7e0b6af">
<data xmlns="urn:xmpp:avatar:data">iVBORw0KGgoAA
... base64 data ...
#2: 5m6XSXU+sAAAAASUVORK5CYII=
</data>
</item>
</items>
</event>
</message>
KAPITOLA 4. REALIZACE
29
Pokud se zjistı́, že daná data nejsou řádně zakončena, uložı́ danou část do mezipaměti a při
přijetı́ dalšı́ části spojı́ obě dohromady a provede kontrolu znovu. Tı́m je zajištěno, že výsledné
XML, které je předáno parseru, je platné.
4.1.3
Udržovánı́ spojenı́
Protože XMPP jako protokol nemá informaci o délce timeoutu TCP/IP spojenı́, zavedl se
takzvaný whitespace ping, kdy server či klient v určitých intervalech zapı́šı́ do kanálu znak
mezery, aby nedošlo k uzavřenı́ spojenı́.
XML validaci sice znak mezery nebránı́, ale nejde o systémové řešenı́. Proto bylo zavedeno
rozšı́řenı́ XEP-0199, které definuje správný XMPP Ping. Ping je definován jako IQ stanza obsahujı́cı́ element ping s namespace urn:xmpp:ping. Pokud protistrana neimplementuje tento
XEP, standardně odpovı́ chybovou hláškou <service-unavailable />. To však má jako vedlejšı́ účinek to, že se oživı́ dané TCP/IP spojenı́.
Při testovánı́ vyvı́jené aplikace byla zjištěna nejmenšı́ hodnota timeoutu u služby serveru
jabber.org a podle nı́ byla nastavena frekvence posı́lánı́ v pětiminutových intervalech.
4.1.4
Zpracovánı́ přijatého DOM
Jak bylo popsáno dřı́ve, výstupem ze třı́dy Socket je DOM reprezentace elementů (přı́padně
elementu) přijatých ze serveru. Pro každý z těchto elementů je pak volána metoda
onDataAvailable třı́dy XMPP. Ta na základě jména a namespace elementu rozhodne, jak
bude program na přijatá data reagovat.
Samotný protokol se může nacházet v několika různých stavech a podle toho také očekávat
přijetı́ různých dat. Toto je popsáno v objektu protocolHandler, který obsahuje logiku zpracovánı́ vzniklé události. Jeho struktura vypadá takto:
protocolHandler: {
’stream-opened’: {
features: function(extxmpp, data) {
...
}
},
...
’connected’: {
message: function(extxmpp, data) {
30
KAPITOLA 4. REALIZACE
...
},
presence: function(extxmpp, data) {
...
},
iq: function(extxmpp, data) {
...
}
}
}
Na ukázce je vidět, že ve stavu stream-opened je očekáván element features. Dále pak, že
pokud je spojenı́ aktivnı́ (stav connected), jsou očekávány elementy message, presence nebo
iq. Pokud je přijat nějaký element, ke kterému nenı́ nalezen přı́slušný handler, je vyvolána
výjimka.
Třı́da XMPP zastřešuje základnı́ práci s protokolem a poskytuje metody pro čtenı́ a zápis do
vzniklého kanálu. Pro čtenı́ jsou zde implementovány události, které vznikajı́ jednak na základě
změn stavu protokolu (např. connected, disconnected) a také přijatých dat (např. message,
presence). Třı́da poskytuje možnost registrace tzv. listeneru, který je informován o vzniku
událostı́ a jsou mu předávána relevantnı́ data.
Listener může implementovat libovolné množstvı́ reakcı́ na události. Přı́kladem může být
následujı́cı́ ukázka kódu, kde jsou zpracovávány události připojenı́, odpojenı́ a přijetı́ oznámenı́
o tom, že druhá entita připravuje IM zprávu.
listener.prototype = {
connected: function(extxmpp, data) {
...
},
disconnected: function(extxmpp, data) {
...
}
composing: function(extxmpp, data) {
...
}
}
KAPITOLA 4. REALIZACE
4.1.5
31
Napojenı́ dalšı́ch komponent do XMPP kanálu
Návrh knihovny umožňuje jednoduché připojenı́ nových komponent systému do XMPP kanálu.
Konkrétnı́ implementace tak může navrhnout svůj vlastnı́ listener, který se připojı́ k události,
kterou chce nový systém sledovat. Pokud by napřı́klad šlo o analýzu přijatých elementů, je
možné využı́t událost data, která vzniká při přı́jmu jakéhokoliv XML. Jiný přı́klad by mohl
být monitoring přı́chozı́ch zpráv, kdy by bylo nutné sledovat událost message.
Jednoduchým přı́kladem by mohl být systém, který by napřı́klad shromažd’oval počet
přijatých elementů pro JID user@server. Ten bylo možno implementovat napřı́klad jako:
var connection = connections.getConnectionByJid(’user@server’);
var elementsCount = 0;
connection.xmpp.registerListenerObject({
data: function() {
elementsCount++;
}
});
4.1.6
DIGEST-MD5
Mimo autentifikačnı́ metody PLAIN bylo nutné implementovat také metodu DIGEST-MD5. Ta
má mezi použı́vanými servery největšı́ podporu právě proto, že je bezpečná1 i pokud je použita
přes nezabezpečené spojenı́.
Metodu popisuje RFC 2831, bohužel je velmi špatně čitelné. Navı́c je třeba, aby se v částech
algoritmu (popsaném v kapitole 3.1.5.3) nepracovalo s obvyklým výstupem MD5 hashovacı́ch
algoritmů (tedy s 32 hexadecimálnı́mi čı́slicemi), ale s hrubými daty.
Proto byla pro výpočet MD5 použita knihovna napsaná v JavaScriptu a veřejně dostupná
pod licencı́ BSD, která poskytuje jako výstup i nekonvertovaná 128 bitová data. Ta jsou potřeba
pro vytvořenı́ odpovědi na DIGEST-MD5 challenge.
4.2
Uživatelské rozhranı́
Uživatelské rozhranı́ bylo implementováno dle návrhu v kapitole 3.3.4, které vycházı́ z již existujı́cı́ho prototypu ExtBrain Communicatoru. Veškerá okna jsou popsána v souborech XUL, z
1
Uměle vykonstruované MD5 kolize sice již byly v roce 2006 prakticky předvedeny, ale v reálném provozu
zatı́m nepředstavujı́ velkou hrozbu.
32
KAPITOLA 4. REALIZACE
nichž hlavnı́ je contactsBox.xul, který je definován jako overlay hlavnı́ho okna poštovnı́ho
klienta.
overlay chrome://messenger/content/messenger.xul \\
chrome://extbrain.thunderbird/content/contactsBox.xul
4.2.1
Seznam kontaktů
Seznam kontaktů byl pomocı́ overlaye přes element s id folderPaneBox vložen pod seznam
účtů a adresářů pošty. Je možné si v něm vybrat, které sloupce budou viditelné a které nikoliv.
Obrázek 4.1: Seznam kontaktů
Seznam kontaktů je tvořen standardnı́ komponentou XUL tree. Ta umožňuje dynamicky
měnit sloupce, které zobrazuje, a zároveň také obsahuje ovládacı́ prvky k řazenı́ podle sloupců.
Komponenta tree se definuje jako
<tree>
<treecols>
KAPITOLA 4. REALIZACE
33
<treecol label="column label" />
</treecols>
<treechildren>
<treeitem>
<treerow>
<treecell label="item label" />
</treerow>
...
</treeitem>
</treechildren>
</tree>
Pomocı́ XUL atributu persist je zajištěno, že si aplikace bude pamatovat i přes své ukončenı́
zobrazené sloupce nebo napřı́klad hodnotu, podle které byl obsah seznamu řazen.
Byla využita již existujı́cı́ implementace nsITreeView, která je popsána v [7].
Seznam všech kontaktů je reprezentován polem contacts uloženým v objektu contactList.
Kontakty, zobrazené v seznamu kontaktů jsou filtrovány z tohoto pole. Je možné vybrat zobrazenı́ pouze on-line uživatelů, je také možné použı́t textový element nad seznamem kontaktů
pro filtrovánı́, resp. hledánı́ mezi zobrazenými kontakty.
Filtrace probı́há při volánı́ metody contactList.search, která do pole contactList.found
zapı́še výsledky daného hledánı́ a ty jsou zobrazeny v elementu tree.
4.2.1.1
Slučovánı́ kontaktů z adresáře a z rosteru
V tomto rozšı́řenı́ existujı́ dva typy kontaktů:
• Kontakt z adresáře poštovnı́ho klienta
• Kontakt z rosteru jednoho z aktivnı́ch účtů
Protože poštovnı́ klient Thunderbird umožňuje uživateli mı́t vı́ce adresářů, v nastavenı́ (viz
kapitolu 4.2.4) je k dispozici výběr adresářů, ze kterých budou kontakty zobrazeny v seznamu.
Každý adresář aplikace Thunderbird je označen vlastnı́m URI, které vypadá napřı́klad jako
moz-abmdbdirectory://abook.mab. Podle tohoto URI se pak v kódu adresář zı́skává za užitı́
rozhranı́ nsIAbManager.
34
KAPITOLA 4. REALIZACE
V seznamu kontaktů jsou vždy zobrazeny sloučeně všechny kontakty z vybraných adresářů.
Naproti tomu kontakt z rosteru účtu je zobrazen pouze v tu chvı́li, kdy je daný účet on-line.
Kontakty z adresářů načı́tá a poskytuje objekt contactSource.
Je běžné, že jeden uživatel XMPP sı́tě vlastnı́ vı́ce různých Jabber ID (obvykle na různých
serverech), a proto byla implementována funkce slučovánı́ kontaktů podle zadaných Jabber ID.
Do základnı́ho formuláře pro úpravu kontaktu z adresáře byla pomocı́ overlay vložena dalšı́
záložka, na které jsou textová pole pro 6 různých Jabber ID. Tyto Jabber ID jsou uloženy ke
kontaktu pomocı́ rozhranı́, které poskytuje nsIAbCard. K zápisu vlastnı́ho atributu ke kontaktu
stačı́ použı́t metodu setProperty.
if (aCard instanceof nsIAbCard) {
for each(var elementId in CardDialogOverlay.customAttributes) {
value = aDoc.getElementById(elementId).value;
aCard.setProperty(elementId, value);
}
}
Při každém připojenı́ některého z účtů dojde k načtenı́ jeho rosteru ze serveru. Pro každý
nový kontakt z rosteru se procházı́ dosavadnı́ seznam kontaktů a kontroluje se, zda v něm
neexistuje kontakt, který by měl již dané Jabber ID definované. Pokud ano, nevytvářı́ se nová
položka seznamu, ale k danému kontaktu se napı́še, že je dostupný pod daným Jabber ID z
daného účtu. Pro rychlé hledánı́ v seznamu je definováno pole jidMap, které obsahuje reference
na kontakty podle Jabber ID. Zjednodušeně je proces naznačen v následujı́cı́m výtažku z kódu:
var tmpContact = contactList.jidMap[jid];
if (tmpContact == undefined) {
// Vytvořenı́ nového kontaktu do seznamu
...
}
tmpContact.addAccount([account, jid]);
tmpContact.addSubscription([account, jid, subscription]);
...
KAPITOLA 4. REALIZACE
4.2.1.2
35
Manipulace s kontakty
S kontakty je možné manipulovat nejen přes nově vytvořený seznam kontaktů, ale také pomocı́
standardnı́ho rozhranı́, které Thunderbird poskytuje. Pokud uživatel kontakt upravı́, je nutné
tuto změnu propagovat do právě zobrazeného seznamu. Rozhranı́ nsIAbManager umožňuje
přidat listener, který je notifikován o každé změně v adresářı́ch. Jsou definovány tři události:
• onItemAdded
• onItemRemoved
• onItemPropertyChanged
Protože kontakt v adresáři Thunderbirdu nemá žádný unikátnı́ identifikátor, kterým by
jej jedinečně určil, je při zakládánı́ kontaktu do seznamu kontaktů vytvořen a uložen vlastnı́
atribut, nazvaný ExtBrainUniqId. Ten je tvořen MD5 hashem jména kontaktu a časového
razı́tka ve chvı́li vytvářenı́. Tento atribut je pouze vytvářen a nenı́ nikdy aktualizován a je
možné podle něj jednotlivé kontakty identifikovat.
Pro obsluhu událostı́ vznikých v kterémkoliv adresáři byl implementován listener, který
na základě změn upravuje zobrazovaný seznam kontaktů. Zejména je nutné hlı́dat změny
v polı́ch obsahujı́cı́ch uživatelem zadaná Jabber ID. Proto byly vytvořeny metody objektu
contactSource:
• mergeCardWithRosters
• unmergeCardToRoster
Tyto metody se starajı́ o sloučenı́ a přı́padné oddělenı́ kontaktů s daným rosterem.
Předpokládejme situaci, kdy uživatel má naplněný seznam kontaktů a jeho jediný XMPP
účet je offline. Jeden z kontaktů adresáře má definovány dvě Jabber ID. Pokud se uživatel
rozhodne XMPP účet připojit, dojde k následujı́cı́mu:
1. Účet se připojı́ a načte roster
2. Projde se zı́skaný roster
• pokud dané Jabber ID odpovı́dá některému z definovaných v kontaktu z adresáře,
je toto ID společně s účtem přidáno ke kontaktu
• pokud dané Jabber ID neexistuje u žádného z kontaktů z adresáře, je zobrazeno v
seznamu samostatně
36
KAPITOLA 4. REALIZACE
Uživatel má nynı́ účet připojen a pokud upravı́ tento sloučený kontakt z adresáře tak,
že odebere Jabber ID, přes které byl tento kontakt s kontaktem z rosteru sloučen, funkce
unmergeCardToRoster tuto změnu detekuje. Z kontaktu pak informace o Jabber ID odebere a
vytvořı́ v seznamu nový záznam. Podobná situace nastane při přidánı́ některého z Jabber ID
v rosteru k některému kontaktu z adresáře – funkce mergeCardWithRosters zrušı́ daný roster
kontakt a přidá informaci o Jabber ID a účtu ke kontaktu z adresáře.
4.2.1.3
Informace o kontaktu
Při najetı́ kurzoru myši na řádek s kontaktem se zobrazı́ okno, které sumarizuje informace, které
jsou o něm dostupné. Toho je dosaženo pomocı́ XUL elementu tooltip, který je dynamicky
přegenerován pokaždé, když se má zobrazit (událost popupshowing).
Obrázek 4.2: Box s informacemi o kontaktu
Při kliknutı́ myšı́ pravým tlačı́tkem je zobrazeno menu, ve kterém může uživatel zahájit
konverzaci (pouze pokud má kontakt definované nějaké Jabber ID), měnit autorizace vůči
vybranému Jabber ID, zobrazit historii konverzacı́ (viz kapitola 4.2.3), začı́t psát nový e-mail,
zahájit hovor na telefonnı́ čı́slo či zobrazit formulář pro úpravu kontaktu. Pokud uživatel chce
upravit data o kontaktu, který nenı́ zatı́m v adresáři, zobrazı́ se okno pro nový kontakt s
předvyplněnými údaji.
4.2.2
Konverzace
Okno s konverzacemi bylo dle návrhu implementováno jako nová záložka poštovnı́ho klienta.
Ta se otevı́rá v přı́padě, že přijde nová zpráva nebo uživatel chce započı́t novou konverzaci.
K vyvolánı́ záložky je použito rozhranı́ Thunderbirdu tabmail. Záložka se pak otevı́rá
následujı́cı́m volánı́m:
var tabmail = document.getElementById("tabmail");
37
KAPITOLA 4. REALIZACE
tabmail.openTab("contentTab", {
contentPage: "chrome://extbrain.thunderbird/content/consoleTab.xul"
});
Obrázek 4.3: Záložka s konverzacı́
Záložka může obsahovat vı́ce konverzacı́; ty jsou pak odděleny systémovými záložkami, kdy
každá je nadepsána jménem kontaktu a je na nı́ zobrazen jeho stav.
Pokud má kontakt definováno vı́ce různých Jabber ID, jsou tyto zobrazeny v menu, ze kterého
může uživatel vybrat, na které JID bude zpráva poslána.
4.2.2.1
Obsluha událostı́
Objekt, který reprezentuje okno s konverzacemi má implementovány handlery pro události
přijetı́ zprávy, změny stavu a zprávy composing (tedy informace o tom, že druhá strana pı́še
zprávu).
• handleStatusChange
38
KAPITOLA 4. REALIZACE
• handleIncomingMessage
• handleContactComposing
Při vyvolánı́ některého z handlerů je okno s informacemi přı́slušně aktualizováno.
4.2.3
Historie konverzacı́
Historie konverzacı́ je ukládána pomocı́ objektu chatDb do databáze SQLite, kterou poskytuje
rozhranı́ mozIStorageService. Tabulka má atributy, které jsou uvedeny v tabulce 4.1.
Název sloupce
Typ sloupce
fromjid
TEXT
tojid
TEXT
direction
TEXT
date
INTEGER
message
TEXT
Tabulka 4.1: SQLite tabulka historie konverzace
Uživatel má možnost zobrazit historii konverzacı́ kliknutı́m na uživatele v seznamu kontaktů,
přı́padně použitı́m tlačı́tka přı́mo v okně s konverzacı́.
Byla převzata i funkčnost z původnı́ho prototypu ExtBrain Communicatoru, kdy se jednotlivé zprávy shlukujı́ do konverzacı́ podle zadaného časového intervalu (viz [7], kapitola 4.4).
4.2.4
Okno nastavenı́
Okno nastavenı́ (obrázek 4.4) je zobrazeno po výběru volby ExtBrain Settings v menu Tools.
V tomto okně má uživatel možnost přidávat a odebı́rat adresáře, které majı́ být použity pro
zobrazenı́ v seznamu kontaktů, a vytvářet a mazat XMPP účty.
Pro vytvářenı́ účtů jsou předdefinovány tři šablony, které uživateli usnadnı́ vyplněnı́ údajů
a nastavenı́ parametrů spojenı́.
• XMPP / Jabber
• GTalk
• Facebook
KAPITOLA 4. REALIZACE
39
Obrázek 4.4: Modálnı́ okno nastavenı́
Šablony jsou definovány v objektu accountPlugins, který definuje tranformačnı́ funkce pro
JID, adresy serveru, portu a zabezpečenı́ spojenı́. Taková šablona musı́ vypadat takto:
var accountPlugins = {
jabber: {
username: ’’,
getUserNamePrompt: function() { },
getConnectHost: function() { },
getPort: function() { },
getSecurity: function() { },
getJid: function() { },
validateJid: function() { }
}
}
Nastavenı́ účtů je uloženo do databáze SQLite podobně jako historie zpráv. Struktura tabulky
je uvedena v tabulce 4.2.
40
KAPITOLA 4. REALIZACE
Název sloupce
Typ sloupce
jid
TEXT
connectHost
TEXT
port
INTEGER
security
INTEGER
enabled
BOOL
Tabulka 4.2: SQLite tabulka nastavenı́ účtů
Hesla k jednotlivým účtům jsou bezpečně uložena v systémovém úložišti, ke kterému poskytuje přı́stup rozhranı́ nsILoginManager.
KAPITOLA 5. TESTOVÁNÍ
41
5 Testovánı́
5.1
Testovacı́ prostředı́
K testovánı́ byla použita dvě různá prostředı́:
• Microsoft Windows XP SP3, Mozilla Thunderbird 3.1.7
• Mac OS X 10.6.5, Mozilla Thunderbird 3.1.7
Protože je Mozilla Application Framework sám o sobě multiplatformnı́, všechny jı́m poskytované funkce musı́ pracovat stejně na všech platformách. Při testovánı́ nebyl zjištěn žádný
zásadnı́ rozdı́l v chovánı́ nebo funkčnosti aplikace ve výše zmı́něných testovacı́ch prostředı́ch.
Je tedy možné předpokládat, že se aplikace bude chovat stejně i na jiných platformách, než na
těch výše uvedených (napřı́klad v operačnı́m systému Linux).
5.2
XMPP knihovna
XMPP knihovna byla testována během vývoje a komunikace se servery byla analyzována pomocı́ implementované debugovacı́ konzole a také pomocı́ sı́t’ového analyzátoru Wireshark.
Komunikace byla testována zejména s těmito servery, poskytujı́cı́mi účty zdarma:
• lokálnı́ ejabberd a OpenFire servery
• jabber.cz
• jabber.org
• jabbim.cz
• talk.google.com
• chat.facebook.com
Komunikace s těmito servery byla monitorována a po dokončenı́ spojenı́ ukládána do souboru, ze kterého byla později analyzována, zda odpovı́dá standardům a zda nedocházelo během
spojenı́ k chybám.
42
KAPITOLA 5. TESTOVÁNÍ
5.3
Uživatelské rozhranı́
Výsledné rozšı́řenı́ poštovnı́ho klienta bylo testováno v součinnosti s vedoucı́m práce. Nalezené
nedostatky byly zaznaménávány a opravovány průběžně během vývoje.
Dalšı́ testovánı́ společně s rozšı́řenı́m doplňku mezi většı́ množstvı́ testerů zajistı́ vedoucı́
práce.
KAPITOLA 6. ZÁVĚR
43
6 Závěr
V rámci této práce byl nastudován protokol XMPP a analyzovány možnosti jeho implementace
v prostředı́ Mozilla Application Frameworku. Následně byla v JavaScriptu implementována
knihovna poskytujı́cı́ připojenı́ ke XMPP serverům. Nakonec bylo dle požadavků vedoucı́ho
práce implementováno rozšı́řenı́ aplikace Mozilla Thunderbird, které funguje jako multifunkčnı́
XMPP klient.
Rozšı́řenı́, které vzniklo v této práci, zpřı́stupňuje kontakty z adresářů Mozilla Thunderbird
do jediného seznamu, umožňuje souběžné připojenı́ a komunikaci z vı́ce XMPP účtů a slučovánı́
kontaktů z nich s kontakty z adresářů poštovnı́ aplikace. Implementuje i podporu jiných komunikačnı́ch sı́tı́ založených na XMPP jako napřı́klad Google Talk nebo Facebook Chat.
Vzhledem k modulárnı́ struktuře implementovaného rozšı́řenı́ bude možné v budoucnosti
využı́t vzniklou knihovnu i pro implementaci dalšı́ch funkčnostı́, napřı́klad posı́lánı́ souborů
nebo dokonce k sestavovánı́ hlasové nebo video komunikace. Do budoucna by také bylo možné
vylepšit XMPP knihovnu pracujı́cı́ nynı́ nad TCP/IP tak, aby pracovala s použitı́m WebSockets.
44
KAPITOLA 6. ZÁVĚR
45
LITERATURA
Literatura
[1] ADIUM. Adium, free instant messaging application [online]. [cit. 21. 12. 2010].
http://adium.im/.
[2] BIELAWA, T. State Transitions during the XMPP Client Connection Process [online].
[cit. 10. 9. 2009].
https://github.com/tbielawa/PAD-XMPP/blob/master/Graph/ConnectionStates.png.
[3] BOSWELL, D. et al. Creating Applications with Mozilla. O’Reilly, 2002.
[4] EJABBERD. ejabberd, the Erlang Jabber/XMPP daemon [online]. [cit. 21. 12. 2010].
http://ejabberd.im/.
[5] IETF.
Extensible Messaging and Presence Protocol (XMPP): Core
[online].
[cit. 20. 12. 2010].
http://tools.ietf.org/html/rfc3920.
[6] IETF. Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence [online]. [cit. 20. 12. 2010].
http://tools.ietf.org/html/rfc3921.
[7] JIROVEC, D. Integrace Mozilla Thunderbird a XMPP [online]. [cit. 10. 11. 2010].
https://dip.felk.cvut.cz/.
[8] MOZILLA. Mozilla Application Framework in Detail [online]. [cit. 7. 12. 2010].
https://developer.mozilla.org/en/mozilla_application_framework_in_detail.
[9] NOVOTNÝ, T. ExtBrain - to simplify everyday tasks [online]. [cit. 21. 12. 2010].
http://extbrain.felk.cvut.cz/.
[10] ORACLE. NetBeans.org [online].
http://netbeans.org/.
[11] SAINT-ANDRE, P. – SMITH, K. – TRONÇON, R.
XMPP: The Definitive Guide.
O’Reilly, 2009.
[12] TEESOFT. FoxBeans NetBeans Plugin [online]. [cit. 20. 12. 2010].
http://plugins.netbeans.org/PluginPortal/faces/PluginDetailPage.jsp?pluginid=4209.
[13] WIRESHARK FOUNDATION. Wireshark [online]. [cit. 21. 12. 2010].
http://www.wireshark.org/.
46
LITERATURA
PŘÍLOHA A. DIAGRAMY A OBRÁZKY
A Diagramy a obrázky
Obrázek A.1: Přechody mezi stavy připojovánı́ XMPP klienta, zdroj: [2]
47
48
PŘÍLOHA A. DIAGRAMY A OBRÁZKY
Obrázek A.2: Návrh třı́d pro XMPP knihovnu
PŘÍLOHA A. DIAGRAMY A OBRÁZKY
Obrázek A.3: Návrh třı́d pro práci s kontakty
49
50
PŘÍLOHA B. SEZNAM POUŽITÝCH ZKRATEK
B Seznam použitých zkratek
IM Instant Messaging
XMPP Extensible Messaging and Presence Protocol
GUI Graphical User Interface (grafické rozhranı́ aplikace)
XML Extensible Markup Language
XUL XML User Interface Language
XBL XML Binding Language
XPCOM Cross Platform Component Object Model
DOM Document Object Model
DTD Document Type Definition
IDE Integrated Development Environment
IVP Integrované Vývojové Prostředı́
HTML Hypertext Markup Language
CSS Cascade Style Sheet
JS Javascript
VCS Version Control System
SSL Secure Sockets Layer
TLS Transport Layer Security
PŘÍLOHA C. INSTALAČNÍ PŘÍRUČKA
51
C Instalačnı́ přı́ručka
C.1
Požadavky k instalaci
K instalaci ExtBrain Communicatoru je nutné mı́t nainstalován jen Mozilla Thunderbird ve
verzi 3.1 a vyššı́; optimálně verzi 3.1.7 (v době psanı́ instalačnı́ přı́ručky nejnovějšı́ verze).
C.2
Instalace ExtBrain Communicatoru
K instalaci je nutné mı́t k dispozici balı́ček extbrain_communicator.xpi. Klikněte v menu
Tools na položku Add-ons.
V něm vyberte vlevo dole možnost Install a vyberte v adresářové struktuře balı́ček xpi.
Obrázek C.1: Okno Add-ons
Thunderbird si vyžádá potvrzenı́, že opravdu chcete neověřený doplněk nainstalovat klikněte na Install now.
52
PŘÍLOHA C. INSTALAČNÍ PŘÍRUČKA
Obrázek C.2: Potvrzenı́ instalace
Pro dokončenı́ instalace je třeba Thunderbird restartovat. Jednoduše to lze udělat kliknutı́m
na tlačı́tko Restart Thunderbird.
Obrázek C.3: Potvrzenı́ instalace
Po restartu aplikace je instalace dokončena.
PŘÍLOHA D. UŽIVATELSKÁ PŘÍRUČKA
53
D Uživatelská přı́ručka
D.1
Nastavenı́ účtů
Po instalaci rozšı́řenı́ je seznam nastavených účtů prázdný. Pro nastavenı́ vyberte z menu
položku Tools a myšı́ klepněte na ExtBrain Settings. Objevı́ se okno, ve kterém můžete vytvořit
nový účet (obrázek D.1).
Pro založenı́ nového účtu vyberte položku Account type a klepněte na tlačı́tko Create new
account. Zobrazı́ se dialog, který vás vyzve k zadánı́ údajů. V přı́padě klasického Jabber účtu
to bude vaše JID, napřı́klad u účtu Facebook Chat jen vaše uživatelské jméno.
Obrázek D.1: Okno Nastavenı́
Po potvrzenı́ je vytvořen nový účet a vy můžete vyplnit jeho heslo do polı́čka Password.
Kontakt lze smazat stisknutı́m tlačı́tka Delete this account a potvrzenı́m následného dialogu.
Pokud nechcete některý z vašich účtů dočasně použı́vat, odškrtněte položku Account enabled.
Účet se tak zakáže a nebude se připojovat.
Pokud provedete změny v nastavenı́ některého z účtů, který je právě připojen, bude po
zavřenı́ okna tlačı́tkem OK tento účet odpojen a znovu připojen.
54
PŘÍLOHA D. UŽIVATELSKÁ PŘÍRUČKA
D.2
Nastavenı́ zobrazovaných adresářů
Aby se v seznamu kontaktů zobrazovaly kontakty z vašich adresářů, je nutné je v okně nastavenı́
(obrázek D.1) ve sloupci Use zaškrtnout.
D.3
Připojenı́ účtů
Pro připojenı́ všech povolených účtů klikněte na obrázek stavu levým tlačı́tkem. Zobrazı́ se menu
(obrázek D.2), ve kterém vyberte požadovaný stav a všechny povolené účty se automaticky
připojı́.
Pro odpojenı́ všech připojených účtů v menu zvolte položku Offline.
Obrázek D.2: Seznam kontaktů
Informace o stavu připojených účtů se zobrazı́, podržı́te-li chvı́li kurzor nad obrázkem stavu
(viz obrázek D.3).
Obrázek D.3: Informace o stavu účtů
Je také možné nastavit stav jednotlivě pro každý z povolených účtů. To můžete provést
kliknutı́m pravým tlačı́tkem na obrázek stavu účtů (viz obrázek D.4).
PŘÍLOHA D. UŽIVATELSKÁ PŘÍRUČKA
55
Obrázek D.4: Nastavenı́ stavu jednotlivých účtů
D.4
Započetı́ konverzace
Dvojitý klik na kontakt v seznamu kontaktů může vyvolat tři různé reakce:
• Pokud má účet definované alespoň jedno Jabber ID a je k dispozici účet, na kterém je k
dispozici, otevře se okno pro IM konverzaci.
• Pokud účet nemá definované žádné Jabber ID, ale je k dispozici jeho e-mailová adresa, je
otevřeno okno pro psanı́ zprávy.
• Pokud neplatı́ ani jedna z výše zmı́něných podmı́nek, je otevřeno okno pro editaci kontaktu.
Pro započetı́ IM konverzace je tedy možné využı́t dvojitý klik na řádek v seznamu kontaktů.
Je ale také možné přı́mo vybrat Jabber ID, kterému chcete zprávu poslat z kontextového menu
kontaktu (obrázek D.5).
Obrázek D.5: Kontextové menu kontaktu
Po kliknutı́ se otevře záložka s oknem IM konverzace (obrázek D.6). Odeslánı́ zprávy provedete bud’ stisknutı́m klávesy Enter nebo kliknutı́m na tlačı́tko Send
56
PŘÍLOHA D. UŽIVATELSKÁ PŘÍRUČKA
Obrázek D.6: Záložka s konverzacı́
D.5
Úprava kontaktu
Položky karty adresáře vybraného kontaktu upravı́te kliknutı́m na položku Edit... v kontextovém menu daného kontaktu.
Pokud chcete pracovat s autorizacemi, vyberte v kontextovém menu položku Subscriptions.
Posı́lat, resp. odebı́rat autorizace můžete pro všechny Jabber ID, které má daný kontakt definované, ze všech vašich připojených účtů.
D.6
Sloučenı́ kontaktu z rosteru s kontaktem z adresáře
Pokud chcete, aby jeden kontakt z adresáře do sebe slučoval vı́ce různých Jabber ID, otevřte
úpravu kontaktu, vyberte záložku ExtBrain JID’s a vyplňte požadovaná Jabber ID do zobrazených polı́. Po uloženı́ kontaktu se tento kontakt automaticky sloučı́ s kontakty v rosteru,
která majı́ zadané Jabber ID.
Pokud Jabber ID z kontaktu odeberete, jednotlivá Jabber ID budou automaticky zobrazena
jako kontakty z rosteru.
PŘÍLOHA D. UŽIVATELSKÁ PŘÍRUČKA
57
Obrázek D.7: Okno pro úpravu přiřazených JID
D.7
Zobrazenı́ historie konverzace
Pro zobrazenı́ historie konverzace vyberte položku kontextového menu kontaktu Show chats
history... nebo klikněte v otevřené IM záložce na tlačı́tko Show history. Bude zobrazeno okno
s historiı́ všech konverzacı́ s daným kontaktem (resp. všemi jeho přiřazenými Jabber ID). Konverzaci zobrazı́te kliknutı́m na řádek v seznamu konverzacı́.
Konverzaci je možné smazat kliknutı́m pravým tlačı́tkem a výběrem položky Delete.
58
PŘÍLOHA D. UŽIVATELSKÁ PŘÍRUČKA
PŘÍLOHA E. OBSAH PŘILOŽENÉHO CD
59
E Obsah přiloženého CD
• build – Připravený instalačnı́ balı́k XPI
• documentation – Dokumentace zdrojových kódu vygenerovaná systémem JsDoc Toolkit
• src – Zdrojové soubory aplikace
• text – Text této práce ve formátech PDF a PS
– source – zdrojové soubory textu této práce
• thubderbird_install – Instalačnı́ soubory aplikace Mozilla Thunderbird pro:
– linux – Linux
– mac – Mac OS X
– windows – Windows
• INSTALL.txt – soubor obsahujı́cı́ instrukce k instalaci
• README.txt – soubor obsahujı́cı́ poznámky o struktuře CD