Synchroniza£ní modul pro Mozilla Thunderbird - ExtBrain

Transkript

České vysoké učení technické v Praze
Fakulta elektrotechnická
Katedra počítačů
Diplomová práce
Synchronizační modul pro Mozilla Thunderbird
Bc. David Kalivoda
Vedoucí práce: Ing. Tomáš Novotný
Studijní program: Elektrotechnika a informatika, strukturovaný,
Navazující magisterský
Obor: Výpočetní technika
květen 2012
iv
v
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).
Ve Starém Hradišti dne 1. 5. 2012
.............................................................
vi
Abstract
Content of this thesis is designing and implementing information synchronization module
for Mozilla Thunderbird over remote storage as IMAP server. Besides common branches of
software engineering, thesis deals with universal principles of synchronization and versioning. There is ExtBrain Sync Protocol which takes control of the synchronization process
described in this thesis.
Abstrakt
Náplní této práce je návrh a implementace synchronizačního modulu informací pro Mozilla
Thunderbird přes vzdálené úložiště v podobě IMAP serveru. Práce se kromě obvyklých
disciplín softwarového inženýrství zabývá obecnými principy synchronizace a verzováním
informací. V práci je popsán obecný ExtBrain Sync Protokol, podle kterého synchronizace
probíhá.
vii
viii
Obsah
1 Úvod
1.1 Motivace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2 Struktura práce . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1
1
1
2 Popis problému, specifikace
2.1 Popis problému . . . . . .
2.2 Specifikace cíle . . . . . .
2.3 Zadání projektu . . . . . .
2.4 Rešerše existujících řešení
.
.
.
.
3
3
3
3
4
cíle
. . .
. . .
. . .
. . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
3 Analýza a návrh implementace
3.1 Analýza . . . . . . . . . . . . . . . . . . . . . . .
3.1.1 Specifikace požadavků . . . . . . . . . . .
3.1.2 Princip synchronizace . . . . . . . . . . .
3.1.3 Vzdálené úložiště - IMAP protokol . . . .
3.1.4 GUI Thunderbirdu s ohledem na kontakty
3.1.5 Mozilla Application Framework . . . . . .
3.2 Návrh implementace . . . . . . . . . . . . . . . .
3.2.1 Struktura aplikace . . . . . . . . . . . . .
3.2.2 Řešení kolizí . . . . . . . . . . . . . . . .
3.2.3 Formát přenášených objektů . . . . . . .
3.2.4 Optimalita datového přenosu . . . . . . .
3.2.5 Rozšíření atributů kontaktů . . . . . . . .
3.2.6 Použité nástroje . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
9
9
9
9
12
15
15
16
16
18
18
18
19
20
4 ExtBrain Sync Protokol
4.1 Definice pojmů . . . . . . . . . . . . . .
4.2 Označení položky . . . . . . . . . . . . .
4.3 Lokální a databázové úložiště . . . . . .
4.4 Vzdálené úložiště . . . . . . . . . . . . .
4.5 Fáze synchronizace . . . . . . . . . . . .
4.6 Fáze import . . . . . . . . . . . . . . . .
4.6.1 Získání UIDNEXT a EXISTS . .
4.6.2 Načtení hlaviček IMAP zpráv . .
4.6.3 Načtení těl a příloh nových zpráv
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
23
23
23
24
24
24
25
26
27
28
ix
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
x
OBSAH
4.7
4.8
4.9
Synchronizační jádro . . . . . . . . . . . .
4.7.1 Vytvoření synchronizační tabulky .
4.7.2 Procházení synchronizační tabulky
Fáze export . . . . . . . . . . . . . . . . .
4.8.1 Krok zápisu . . . . . . . . . . . . .
4.8.2 Krok přesouvání . . . . . . . . . .
Paralelní přístup . . . . . . . . . . . . . .
4.9.1 Zamykání vzdáleného úložiště . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
5 Realizace
5.1 Obecný synchronizační modul . . . . . . . . . . . . . . . .
5.1.1 Průběh volání v jednotlivých fázích synchronizace
5.2 Databázové úložiště . . . . . . . . . . . . . . . . . . . . .
5.3 Obsluha IMAP úložiště . . . . . . . . . . . . . . . . . . .
5.3.1 Posloupnost IMAP příkazů . . . . . . . . . . . . .
5.3.2 Struktura obsluhy volání IMAP příkazu . . . . . .
5.3.3 Zamykání vzdáleného úložiště . . . . . . . . . . . .
5.3.4 IMAP knihovna . . . . . . . . . . . . . . . . . . .
5.4 Synchronizační modul kontaktů . . . . . . . . . . . . . . .
5.4.1 Implementace . . . . . . . . . . . . . . . . . . . . .
5.4.2 Definice formátu obsahu přenášených zpráv . . . .
5.4.3 Serializace a deserializace kontaktů . . . . . . . . .
5.4.4 Chyba v jádru Thunderbirdu . . . . . . . . . . . .
5.4.5 Řešení kolizních situací . . . . . . . . . . . . . . .
5.5 Grafické uživatelské rozhraní . . . . . . . . . . . . . . . .
5.5.1 Rozšíření atributů kontaktu . . . . . . . . . . . . .
5.5.2 Wizard na tvorbu účtů . . . . . . . . . . . . . . . .
5.5.3 Obsluha synchronizace . . . . . . . . . . . . . . . .
6 Testování
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
28
29
31
36
37
38
39
39
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
41
41
41
43
44
44
45
46
47
47
47
47
48
48
50
50
50
50
51
53
7 Závěr
55
7.1 Možná další rozšíření . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
Literatura
57
A Seznam použitých zkratek
59
B Obrázky a diagramy
61
C Instalační příručka
67
C.1 Instalace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
C.2 Vytvoření účtu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
C.3 Spuštění synchronizace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
D Obsah přiloženého CD
71
Seznam obrázků
2.1
2.2
2.3
Okno se zobrazením průběhu synchronizace (SyncKolab) . . . . . . . . . . . .
Kolizní okno doplňku SyncKolab . . . . . . . . . . . . . . . . . . . . . . . . .
Rozšíření položek v kontaktech v doplňku gContactSync . . . . . . . . . . . .
3.1
3.2
3.3
Grafické rozhraní editace kontaktu v Thunderbirdu 11.0.1 . . . . . . . . . . . 15
Návrh třívrstvé architektury . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Návrh okna pro řešení kolizních situací . . . . . . . . . . . . . . . . . . . . . . 18
4.1
4.2
4.3
4.4
4.5
4.6
Fáze procesu synchronizace . . . . . . . . . . . . . . .
Stavový diagram fáze import . . . . . . . . . . . . . .
Stavový diagram jádra synchronizace . . . . . . . . . .
Poslední podmínka průchodu synchronizační tabulkou
Stavový diagram fáze export . . . . . . . . . . . . . .
Stavový diagram zamykání vzdáleného úložiště . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
25
26
29
32
36
40
5.1
5.2
5.3
5.4
5.5
5.6
Class diagram synchronizačního modulu . . . . .
Sekvenční diagram fáze import . . . . . . . . . .
Sekvenční diagram fáze export . . . . . . . . . .
Relační databázový model . . . . . . . . . . . . .
Okno pro editaci kontaktů s rozšířenými atributy
Okno informující o průběhu synchronizace . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
42
43
43
44
51
52
B.1
B.2
B.3
B.4
B.5
Návrh okna pro editaci kontaktů . . . . . .
Sekvenční diagram všech fází synchronizace
Volání IMAP příkazů v initialSequence . . .
Volání IMAP příkazů v importSequence . .
Volání IMAP příkazů v exportSequence . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
61
62
63
64
65
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
4
5
7
C.1 Úvodní okno průvodce pro vytváření účtů . . . . . . . . . . . . . . . . . . . . 68
C.2 Okno se seznamem složek na serveru . . . . . . . . . . . . . . . . . . . . . . . 68
C.3 Spuštění synchronizace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
xi
xii
SEZNAM OBRÁZKŮ
Seznam tabulek
3.1
3.2
Tabulka synchronizace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Trojcestné slučování - příklad . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.1
4.2
4.3
4.4
4.5
4.6
Načtení hlaviček IMAP zpráv . . . . . . . .
Načtení těl IMAP zpráv . . . . . . . . . . .
Synchronizační tabulka - příklad . . . . . .
Možné situace v synchronizační tabulce . .
Příklad struktury objektu objectsToExport
Příklad struktury objektu objectsToDelete .
5.1
JSON atributy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
27
29
30
31
35
35
B.1 Kontakt v JSON podobě . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
xiii
xiv
SEZNAM TABULEK
Kapitola 1
Úvod
1.1
Motivace
Při současném trendu velkého rozvoje chytrých telefonů a dalších jiných mobilních zařízení je
kladen velký důraz jednak na zabezpečení takových zařízení, ale také na přenášení souborů,
kontaktů, záložek a dalších informací, které je výhodné mít ve stejných verzích na všech
zařízeních. Při více než dvou používaných zařízeních pro služby jako volání, psaní e-mailů
atd. již nestačí synchronizovat tato zařízení pouze mezi sebou, ale při dodržení obvyklých
bezpečnostních pravidel je lepší využívat centrální úložiště, na kterém jsou data uchovávána. Pomocí klientských aplikací na jednotlivých zařízeních jsou na toto centrální úložiště
data odesílána, při synchronizačním procesu data z úložiště získávána, při výskytu kolizních
situací musí aplikace zajistit její vyřešení. Nejde jen o to přesunovat soubory a informace
z jednoho zařízení na druhé, nýbrž je přenášet obousměrně, pokud možno v reálném čase
a po každé změně na jedné ze stran. Tento trend se velmi přibližuje modelu využívání IT
technologií zvaný jako „cloud computing“. V každém případě může služby „v cloudu“ velmi
dobře doplňovat.
Pro přiblížení motivace pro tuto práci můžeme vzít běžnou konkrétní situaci: máme
mobilní telefon s kontakty a na jiném zařízení e-mailového klienta. V tomto případě je
samozřejmě účinné mít na všech zařízeních kontakty sdílené tak, abychom v případě změny
např. e-mailu u jednoho kontaktu editaci nemuseli provádět několikrát. Změníme-li kontakt
na jednom zařízení, chceme, aby se kontakt v této verzi uložil „někam na server“, odkud si
jeho změny na jiném zařízení nahrajeme.
Cílem této práce je návrh a implementace aplikace, která bude umožňovat synchronizaci informací v e-mailovém klientu Mozilla Thunderbird přímo v jeho prostředí, bude se
jednat o zásuvný modul. Řešení poskytující synchronizaci například kontaktních údajů již
samozřejmě existují, žádné z nich ovšem není nijak obecné a většinou nesplňují požadavky
na dlouhodobé bezproblémové nasazení.
1.2
Struktura práce
V následující kapitole se zaměřím na konkrétní popis cílů práce a podrobný rozbor existujících řešení. Díky inspiraci a poučení se z nedostatků konkurence v kapitole Analýza a
1
2
KAPITOLA 1. ÚVOD
návrh popíšu jaké konkrétní postupy jsem se rozhodl zvolit. Zaměřím se zde i na obecné
principy synchronizace. V kapitole ExtBrain Sync Protokol bude místo pro podrobný popis
protokolu, podle kterého se synchronizace řídí. Pomocí stavových diagramů a konkrétního
příkladu provázejícího celou tuto kapitolu bude vysvětlen flow dat při synchronizaci. Kapitola Realizace se bude týkat konkrétních tříd výsledné implementace. Kapitola Testování
bude věnována popisu testů, které byly na implementovanou aplikaci provedeny. V závěru
se pokusím shrnout výsledek projektu s ohledem na zadání diplomové práce, praktickou
použitelnost a nastínit možnosti budoucích rozšíření.
Kapitola 2
Popis problému, specifikace cíle
2.1
Popis problému
E-mailový klient Mozilla Thunderbird, tak jak je to u podobných aplikací běžné, obsahuje
adresář s kontakty. Vstup kontaktů do adresáře je možný přes ruční zadávání v grafickém
uživatelském rozhraní, nebo přes funkci import. Ta ve verzi Thunderbird 11.0 podporuje
následující formáty: vCard, LDIF, textové formáty s daty oddělenými tabelátorem nebo
čárkou (.csv) a přímý import adresářových souborů z aplikací Outlook, Outlook Express a
Eudora.
V jádru aplikace chybí možnost synchronizace či uložení na sdílené úložiště. Synchronizací se zabývá několik doplňků Thunderbirdu (jejich seznam a stručná rešerše je uvedena
dále v této kapitole). Tyto doplňky synchronizují kontakty z adresáře do složky na lokálním
úložišti, několik z nich podporuje synchronizaci se službou Google Contacts a některé umožňují jako vzdálené úložiště zvolit IMAP server. Toto je užitečné například pro korporátní
uživatele, kde s ohledem na bezpečnost chceme využít například firemní IMAP server.
Užitečnost synchronizace v e-mailovém klientu se však netýká pouze kontaktů, ale i
událostí v kalendáři, nebo například poznámek k e-mailovým zprávám.
2.2
Specifikace cíle
Cílem této práce je návrh a implementace zásuvného modulu do Mozilla Thunderbird rozšiřujícího jej o možnosti synchronizace informací pomocí IMAP protokolu. S využitím tohoto
modulu bude pak implementováno rozšíření pro synchronizaci kontaktů. Atributy kontaktů
v Mozilla Thunderbird budou rozšířeny na formát odpovídající atributům v OS Android.
Zásuvný modul bude napsán v jazyce JavaScript obvyklém pro implementaci rozšíření Thunderbirdu.
2.3
Zadání projektu
Diplomová práce byla zadána v rámci projektu ExtBrain [1], který se zaměřuje na vývoj
aplikací usnadňujících každodenní práci na PC. Projekt ExtBrain již zahrnuje některé aplikace pro Mozilla Application Framework, například e-mailového klienta a IM komunikátor.
3
4
KAPITOLA 2. POPIS PROBLÉMU, SPECIFIKACE CÍLE
Synchronizační modul bude po dokončení integrován do většího celku sdružujícího všechna
ExtBrain rozšíření pro Mozilla Thunderbird.
2.4
Rešerše existujících řešení
V následujících odstavcích jsou shrnuty výsledky zkoušení několika zásuvných modulů do
Thunderbirdu včetně heslovitého zhodnocení kladných a záporných vlastností, které tyto
moduly vykazují.
2.4.1
SyncKolab
Obrázek 2.1: Okno se zobrazením průběhu synchronizace (SyncKolab)
Doplněk Thunderbirdu přináší synchronizaci kontaktů přes IMAP server. Ke každé složce
kontaktů, kterou chce uživatel synchronizovat, musí v rozšíření vytvořit samostatný účet.
Verze kontaktů jsou ukládány lokálně ve formátu xml nebo vcard v adresáři profilu, tyto
soubory jsou při synchronizaci přílohou zprávy na serveru, stejně jako fotky, pokud jsou
ke kontaktu přiřazeny. Při smazání fotky v jiném profilu nedojde ke smazání souboru s
fotkou v aktuálním profilu. Fotky jsou uloženy ve složce profilu ve Photos. Autor píše, že na
verzi Thunderbird 3 by měl uživatel používat noční sestavení, ani s ním však v době psaní
2.4. REŠERŠE EXISTUJÍCÍCH ŘEŠENÍ
5
této práce nefunguje GUI umožňující výběr verze při kolizi. Dialog upozorňující na kolizi se
uživateli zobrazí (viz obr. 2.2), tlačítka označující, zda uživatel chce zachovat lokální verzi,
nebo verzi ze serveru, však nereagují. Především ale chybí zobrazení kolidujících položek.
Jedinou možností je tedy zvolit Skip, což vyvolá přeskočení této kolize a kontakt tak není v
konzistentním stavu. SyncKolab nijak nerozšiřuje položky kontaktů, hodí se tak pro použití
mezi více klienty používajícími pouze Thunderbird. Nezotaví se při změně názvu adresáře
(addressBook v Thunderbirdu je uložen jako název, ne URI). Všechny informace o účtech
jsou uloženy v preferencích v about:config.
Synchronizované kontakty: jakékoli
Úložiště: IMAP server, složka v profilu a TH
Fotky: ano
Kolize: ano, ale nefunkční GUI
+
+
+
−
více složek k synchronizaci
použití jakéhokoli IMAP serveru
podpora fotek
nefungující podpora kolizních situací
Obrázek 2.2: Kolizní okno doplňku SyncKolab
2.4.2
Zindus
Doplněk Thunderbirdu přináší synchronizaci kontaktů s Google kontakty nebo Zimbra Server (open-source server pro Linux a Mac umožňující správu e-mailů, kontaktů a kalendářů
[2]). Možnost synchronizace pouze kontaktů v účtu Google (ne libovolné kontakty do složky
na IMAP serveru). Podpora Google Groups v kontaktech. Zindus nijak nerozšiřuje položky
kontaktů. Synchronizace probíhá pouze na úrovni vybraných položek (např. adresa není
zahrnuta vůbec). V doplňku neexistuje okno s kolizemi, bez uživatelova potvrzení přepisuje verzi na serveru lokálními změnami. Nemá žádné interní úložiště pro verze kontaktů.
Nepodporuje mail listy ani fotky.
6
Synchronizované kontakty: google contacts
Úložiště: pouze server a TH
Fotky: ne
Kolize: ne
−
−
−
2.4.3
synchronizace pouze kontaktů v účtu Google
chybí podpora kolizních situací (serverová verze je při kolizi přepsána lokální)
nepodporuje fotky u kontaktů
ThunderSync
Doplněk Thunderbirdu přináší synchronizaci přes úložiště na lokálním disku ve formě vCard
souborů. Lze synchronizovat jakýkoli adresář v Thunderbirdu, pro každý je možné zvolit
složku na disku, do které budou soubory zapisovány. Soubory jsou zapisovány jako vCard 2.1.
ThunderSync nijak nerozšiřuje položky kontaktů, hodí se tak pro použití mezi více klienty
používajícími pouze Thunderbird. Všechny informace o účtech jsou uloženy v preferencích
v about:config. Zotaví se ze změny názvu adresáře v Thunderbirdu, addressBook je uložen
jako URI, ne jako jeho název. Podporuje fotky, ty jsou uloženy přímo ve vCard souboru
jako base64. Při kolizi není žádná verze původní, pouze aktuální z adresáře a vzdálená ze
souboru.
Synchronizované kontakty: jakékoli
Úložiště: pouze složka a TH
Fotky: ano
Kolize: ano
+
+
−
2.4.4
synchronizace jakéhokoli adresáře
podpora fotek
úložiště pouze na lokálním disku
Google Contacts
Doplněk Thunderbirdu umožňuje synchronizaci s Google kontakty. Podporovány jsou tak
pouze kontakty v účtu Google. Synchronizaci nelze ručně vyvolat, lze pouze zvolit, zda
zahájovat synchronizaci při startu Thunderbirdu. Změny v kontaktech jsou pak zapisovány
na server ihned po uložení změny v kontaktu, nekontroluje se ale jejich změna na serveru.
Verze na serveru je vždy přepsána lokální. Podporuje fotky u kontaktů, lokálně je ukládá
do adresáře GoogleContacts/Photos v profilu.
Úložiště: pouze server a TH
Fotky: ano
Kolize: ne (vždy přepis serverové verze)
+
−
−
podpora fotek
chybí podpora kolizních situací (serverová verze je při kolizi přepsána lokální)
2.4. REŠERŠE EXISTUJÍCÍCH ŘEŠENÍ
7
Obrázek 2.3: Rozšíření položek v kontaktech v doplňku gContactSync
2.4.5
gContactSync
Doplněk Thunderbirdu umožňuje synchronizaci s Google kontakty. Lze vytvořit více účtů,
každý však bude spolupracovat pouze s Google kontakty. Toto lze tedy prakticky použít
pouze v situaci, máme-li více Google účtů. Složky s kontakty v Thunderbirdu pak budou
odpovídat kontaktům uloženým v jednotlivých účtech. Neobsahuje okno na řešení kolizí,
směr přepisu při konfliktu uživatel volí v nastavení předem. Podporuje fotky, jsou uloženy ve
standardním adresáři pro fotky v Thunderbirdu (ProfD/Photos). Doplněk rozšiřuje položky
kontaktů tak, aby bylo možné je pohodlně namapovat na základní položky použité v Google
kontaktech (viz obr. 2.3). Zotaví se ze změny názvu adresáře v Thunderbirdu, addressBook
je uložen jako URI, ne jako jeho název.
Úložiště: google server, soubor se zálohou v profilu a TH
Fotky: ano
Kolize: ne (směr přepisu lze měnit v nastavení rozšíření)
+
−
−
2.4.6
podpora fotek
chybí podpora kolizních situací
Addressbook Synchronizer
V průběhu implementační fáze se objevilo ještě jedno rozšíření Thunderbirdu s názvem Addressbook Synchronizer. Podle popisu umožňuje synchronizovat kontakty přes lokální
adresář, FTP, WebDAV a IMAP server. Při testování jsem však došel k závěru, že synchronizace zde není úplná a funkční. Program je založen na výměně souborů ukládaných do
8
jednotlivých úložišť (složka v případě lokálního disku, FTP a WebDAVu, příloha e-mailu
v případě IMAP serveru). Soubory však nereprezentují jednotlivé kontakty, nýbrž jsou to
soubory s příponou .mab obsahující celý adresář. Ačkoli nastavení programu se zmiňuje o
možnostech nastavení chování při kolizích, vždy dochází pouze k přepisu celého adresáře
buď ve vzdáleném úložišti, nebo v Thunderbirdu. Pro práci s takovým rozšířením bychom
museli pečlivě dbát na rozlišování akcí, které vyvoláme. Upload striktně přepíše vzdálenou
verzi, download přepíše lokální změny.
Kapitola 3
Analýza a návrh implementace
3.1
3.1.1
Analýza
Specifikace požadavků
Soustředím se na vytvoření aplikace, která bude vykazovat následující vlastnosti:
∙ obecný synchronizační modul bude mít charakter knihovny,
∙ synchronizovány budou nejen textové položky, ale také přílohy v binárním formátu,
∙ při synchronizaci se budou kompletně řešit kolizní situace,
∙ obecný synchronizační modul bude využit pro implementaci synchronizace kontaktů,
∙ položky kontaktů v Thunderbirdu budou rozšířeny tak, aby lépe odpovídaly kontaktům
ve službě Gmail a v OS Android,
∙ položky budou ukládány každá zvlášť (jedna položka = jeden soubor/e-mail),
∙ synchronizace bude podporovat všechny běžně dostupné IMAP servery,
∙ synchronizace bude co nejoptimálnější ohledně datového přenosu,
∙ aplikace bude podporovat více adresářů a synchronizaci na více IMAP serverech.
3.1.2
Princip synchronizace
Synchronizací je pro účel této práce myšlena jednorázová akce vyvolaná uživatelem či automaticky vedoucí k dosažení stavu, kdy si obsahem a strukturou odpovídají data v lokálním
adresáři a ve vzdáleném úložišti. Na straně lokálního adresáře synchronizaci obsluhuje klientská aplikace, vzdálené úložiště je obsluhováno serverem. Za položky považujeme jednotlivé
entity nacházející se v adresáři, mohou jimi být soubory nebo např. kontakty. Položky jsou
tvořeny z atributů.
9
10
KAPITOLA 3. ANALÝZA A NÁVRH IMPLEMENTACE
3.1.2.1
Základní princip
Základní princip synchronizace lze vysvětlit jednoduchým způsobem:
1. zjistíme, jaké změny jsou ve vzdáleném úložišti (rozhodně se nechceme zabývat srovnáváním všech položek, pokud nenastala žádná změna),
2. zjistíme, k jakým změnám došlo v lokálním adresáři od poslední synchronizace,
3. ze změněných položek si vytvoříme tabulku, kde jeden sloupec označuje lokální změny,
druhý změny ve vzdáleném adresáři, tuto tabulku řádek po řádku procházíme,
4. je-li změna na lokální straně, přepíšeme verzi ve vzdáleném úložišti a naopak.
3.1.2.2
Kolizní situace
Problém nastává v situaci, kdy se v jednom řádku tabulky vyskytuje hodnota v obou sloupcích. V takové chvíli nejsme schopni jednoduše určit, která verze má být upřednostněna.
Tuto situaci lze označit jako kolizní. Kolize tedy nastává v případě, že se klientská aplikace
snaží do vzdáleného úložiště vložit změněnou verzi položky z lokálního adresáře, odpovídající položka na vzdáleném úložišti však byla od předchozí sychronizace změněna. (Tato
změna musela být provedena jinou klientskou aplikací.)
Aby se předešlo takovýmto kolizím v případě současných změn na obou stranách, je
možné na klientské straně synchronizaci podporovat databází, sloužící k uložení předchozích
verzí dat. V tomto ohledu se pak synchronizace podobá procesu verzování, kdy se ukládá
historie provedených změn nad daty tak, aby bylo možné rozpoznat, kdy byla jaká verze
vytvořena. Díky tomu lze například poznat novější verzi a tu při synchronizaci automaticky upřednostňovat. I přesto ale mohou nastávat situace, kdy není aplikace sama schopna
rozhodnout, která verze dat by měla být ponechána. Za pomoci znalosti předchozích změn
při synchronizaci tedy klientská aplikace vyřeší některé situace sama, na některé vyžaduje
zásah uživatele a jeho rozhodnutí. Při verzování změn do synchronizační tabulky přibude
jeden sloupec s označením jako původní (databázová) verze. Verzování změn nad daty má
ještě jednu výhodu, změny lze využít jako zálohu.
V případě verzovacích systémů, které se v současné době používají především na podporu
vývoje softwaru při verzování zdrojových kódu, ke kolizím dochází v případě, že například
více vývojářů mění na svých lokálních počítačích jeden soubor zdrojového kódu, který poté
odešlou do repozitáře1 . Verzovací nástroje v tomto případě většinou nabízí možnost sloučení
souboru, což je proces, při kterém se řádky z jednotlivých verzí zdrojových souborů vkládají
za sebe, až vytvoří jeden výsledný. Slučování (merge) probíhá částečně automaticky, ale
vyžaduje rozhodnutí uživatele v případě nesrovnalostí.
Při rešerši existujících synchronizačních aplikací jsem se často setkal s přístupem, že
kolize jsou řešeny sice automaticky, ale podle předem daného scénáře, např. tak, že je vždy
přepsána lokální verze verzí ze vzdáleného úložiště.
1
ve verzovacích nástrojích se vzdálené úložiště nazývá obvykle repozitář
3.1. ANALÝZA
3.1.2.3
11
Identifikátory
Položky jsou od sebe odlišovány pomocí unikátního atributu označeného jako UUID (beremeli v úvahu např. možnou změnu jména a příjmení u kontaktu je UUID nezbytností), jejich
konkrétní verze jsou pak označovány atributem RevId (celé číslo). RevId v průběhu života
položky roste o 1 s každou změnou. Pomocí dvojice RevId a UUID jsme schopni naplnit
tabulku synchronizace, rychle skrze ní procházet a rozhodovat o akcích, které mají být vykonány.
3.1.2.4
Příklad procházení synchronizační tabulkou
Ukázka toho, jak může synchronizační tabulka vypadat včetně akcí, které je nutné při synchronizaci vykonat, je v tabulce 3.1. Protože není nutné vždy porovnávat přímo hodnoty
položek, ale pouze jejich čísla revizí, jsou v tabulce uvedena pouze tato čísla.
UUID
53
54
55
58
60
62
67
68
71
83
local
3
1
20
15
15
32
1
RevId
remote
2
2
28
15
20
1
3
10
database
2
1
20
14
14
10
32
akce
zápis lokální verze do vzdáleného úložiště
přepis lokální verze vzdálenou
přepis lokální verze vzdálenou
kolize
kolize
vytvoření nové položky v lokálním adresáři
vytvoření nové položky v lokálním adresáři
smazání položky ve vzdáleném úložišti
smazání položky v lokálním adresáři
nová lokální položka, zápis do vzdáleného úl.
Tabulka 3.1: Tabulka synchronizace
Ve chvíli vyvolání synchronizace je každá lokální položka v jednom ze stavů:
buď je identická s verzí v databázi (pak local.RevId==database.RevId),
nebo je změněná a její RevId je oproti databázovému o 1 vyšší.
RevId vzdálené verze se může od RevId lokální verze lišit o libovolné celé číslo, nesmí ale
být menší než RevId v databázi. Je-li vzdálené RevId vyšší než lokální o 2 a více, položka
byla v době od poslední synchronizace několikrát změněna jiným klientem. Tuto situaci
ukazují položky s UUID 55 a 60. První vyvolá přepis lokální verze, druhá vyvolá kolizi
(všimněme si, že lokální položka je oproti databázi změněna).
Zápis verze do databáze je realizován při každém zápisu/přepisu do vzdáleného nebo
lokálního úložiště. Absence RevId je považována za absenci položky s daným UUID v daném
úložišti. Tak je možné pro položku s UUID 71 rozhodnout, že byla ve vzdáleném úložišti
smazána a odstranit ji i lokálně. Není-li UUID nalezeno v databázi ani ve vzdáleném úložišti,
12
je to známka toho, že položka byla nově vytvořena – položka s UUID 83. Položky s UUID
62 a 67 naopak existují pouze ve vzdáleném úložišti a budou synchronizovány stažením do
lokálního adresáře.
Z tabulky lze také pozorovat, že číslo RevId z lokálního adresáře a z databáze se liší vždy
maximálně o 1. Je to dáno tím, že číslo verze se zvyšuje jen při vyvolání synchronizace, ne
při každé editaci položky a jejím uložení.
3.1.2.5
Trojcestné slučování
Změnu položky (souboru, kontaktu) v lokálním adresáři poznáme buď pomocí příznaku
označujícího čas poslední změny, nebo přímým porovnáním obsahu položky s poslední verzí
v databázi. Nejsou-li shodné, uživatel položku změnil a měla by tedy být označena vyšším
RevId a následně distribuována na vzdálené úložiště a do databáze. Pokud se ve vzdáleném
úložišti mezitím objevila položka s vyšším RevId, než tím, které máme pro položku naposledy registrované v databázi, nastává kolize. Díky verzování jsme schopni uživateli zobrazit
tabulku s jednotlivými atributy položky a nabídnout předpokládané vyřešení. Kolize se tak
může řešit tzv. trojcestným slučováním (3-way merge), kde jedna verze je lokální, druhá
vzdálená a třetí z databáze (lze označit jako původní). Slučování se neprovádí nad celou položkou jako nedělitelnou množinou, nýbrž nad jednotlivými atributy, ze kterých se výsledná
položka složí. Výsledná verze položky tak může obsahovat jednotlivé atributy pocházející
každý z jiné verze.
Ukázka trojcestného slučování je v tabulce 3.2. Je-li lokální a vzdálená verze stejná,
řešení je snadné, výsledkem bude jedna z těchto verzí. Jsou-li jakékoli jiné dvě verze shodné,
výsledkem je verze třetí. Nerovnají-li se hodnoty žádné dvojice odpovídajících atributů je
o vyřešení této kolize nutné požádat uživatele. V tabulce jsou zvýrazněny vždy dvojice
shodných hodnot atributů. Případ shodnosti celé trojice hodnot (jméno, příjmení) je při
slučování vyhodnocen jako shoda lokální a vzdálené verze.
atribute
jméno
příjmení
telefon
zaměstnání
web
bydliště
local
Karel
Poláček
504-111
reportér
www.polacek.cz
Praha
remote
Karel
Poláček
504-222
reportér
www.ln.cz
Hradec Králové
database
Karel
Poláček
504-111
spisovatel
www.ln.cz
Rychnov n. Kněžnou
result
Karel
Poláček
504-222
reportér
www.polacek.cz
???
Tabulka 3.2: Trojcestné slučování - příklad
Algoritmus slučování je možné v pseudo kódu napsat způsobem viz algoritmus 3.1.
Kvalitní článek zabývající se trojcestným slučováním a algoritmem diff3, který je jeho
implementací, byl vydán na University of Pennsylvania ve spolupráci s Yahoo [3].
3.1.3
Vzdálené úložiště - IMAP protokol
IMAP (Internet Message Access Protocol) je protokol umožňující vzdálený přístup k elektronickým zprávám na serveru a manipulaci s nimi (publikováno v RFC 3501[4]). Protokol
3.1. ANALÝZA
13
Algoritmus 3.1 trojcestné slučování
for all atribute in item do
if ( local.atribute == remote.atribute ) then
result.atribute = local.atribute;
continue;
end if
if ( local.atribute == database.atribute ) then
result.atribute = remote.atribute;
continue;
end if
if ( remote.atribute == database.atribute ) then
result.atribute = local.atribute;
continue;
end if
result.atribute = askUser(atribute);
◁ kolize nemůže být automaticky vyřešena
end for
pracuje na klasickém modelu klient-server, klient odesílá příkazy serveru, který na ně reaguje a odpovídá. Protokol neslouží k odesílání e-mailů (jako SMTP), odchozí zprávy tak
nebudou e-maily v pravém slova smyslu. Odchozí zprávy od klienta na server jsou pouze
uloženy do e-mailové schránky, odkud mohou být později staženy jiným klientem.
Většina dnešních běžně dostupných serverů vyžaduje zabezpečení komunikace, nejčastěji
SSL. Jelikož se jednotlivé servery v přesných implementacích liší, budeme při vývoji brát za
důležitou funkčnost na serveru imap.gmail.com, imap.aol.com a imap.feld.cvut.cz.
3.1.3.1
IMAP zprávy
Protokol byl vytvořen kompatibilní s RFC 822 [5], které definuje strukturu internetových
textových zpráv. V tomto RFC je popsána zpráva jako text členěný na jednotlivé řádky
složený z hlavičky a nepovinně těla zprávy [6] . Tyto části jsou od sebe odděleny prázdným řádkem. Každá položka hlavičky musí začínat na novém řádku a doporučení umožňuje
přidávat i hlavičky vlastní. Toho bude využito pro uchování UUID jednotlivých kontaktů.
Příklad zprávy včetně standardních hlaviček:
1
2
3
4
5
6
7
8
9
MIME-Version: 1.0
Received: by 10.112.23.8 with HTTP; Wed, 4 Feb 2012 14:14:07 -0800 (PDT)
Date: Wed, 4 Feb 2012 23:14:07 +0100
Delivered-To: [email protected]
Message-ID: <[email protected]>
Subject: Greeting
From: Imap Imap <[email protected]>
To: Imap Imap <[email protected]>
Content-Type: text/plain; charset=UTF-8
10
11
Hello Mike!
14
Obsah zpráv včetně hlaviček smí obsahovat pouze ASCII znaky, pro přenos znaků mimo
ASCII je tedy nutné znaky převést například pomocí quoted printable, což je způsob přenosu
8 bitových znaků přes 7 bitový kanál. Souhrnně se rozšířením elektronických zpráv o znaky
mimo ASCII zabývá technologie Multipurpose Internet Mail Extensions (MIME) popsaná
v RFC 2045 a 2046. Quoted printable je jedním z možných způsobů tohoto rozšíření.
Ke zprávám je možné přikládat přílohy zakódované ve formátu base64 (taktéž součástí
standardu MIME) toho bude využito pro synchronizaci fotek, které jsou součástí kontaktů.
3.1.3.2
Přidělování RevId
Pro ukládání zpráv na server budeme používat složku v existující e-mailové schránce. Dle
definice protokolu je každé zprávě na serveru přiřazen jednoznačný číselný identifikátor UID
o délce 32 bitů. Protokol zaručuje, že žádná jiná zpráva v dané složce nebude mít UID se
stejnou hodnotou. Při vložení zprávy na server je přiřazen identifikátor (číslo) vyšší, než
předchozí zprávě. Tato vlastnost přesně odpovídá potřebám pro verzování položek, přiřazení atributu RevId jednotlivým verzím. Položky nebudou sice moci se svým RevId začínat
na 1, jako je tomu v tabulce 3.1, odpadne však starost o udržování konzistentního stavu
RevId. Každá položka ve vzdáleném úložišti tedy bude identifikována buď pomocí UUID
(identifikátor položky) nebo RevId (UID zprávy dle IMAP protokolu, identifikátor verze).
V obou případech jednoznačně.
3.1.3.3
IMAP příkazy
Protokol IMAP v základní verzi obsahuje na 20 příkazů, klíčovými pro přenos zpráv jsou:
FETCH – pro načtení zpráv ze složky na serveru. Podporuje celou řadu parametrů pro
získání konkrétních částí zpráv (bude využito pro minimalizaci přenesených dat).
APPEND – pro uložení zprávy do složky na server. Zprávě je po uložení přiřazeno jednoznačné UID, které bude využito na verzování kontaktů (viz dále).
Všechny příkazy pro manipulaci se zprávami na serveru vyžadují parametr identifikující
zprávu nebo sekvenci zpráv. Tímto parametrem je standardně pořadí zprávy ve složce; toto
pořadí se logicky při odstranění zprávy mění. Druhou možností, kterou IMAP příkazy podporují, je identifikace zprávy pomocí UID. Toto UID zůstává po celou dobu existence zprávy
v dané složce neměnné. (RFC definuje ještě atribut UID validity, které připouští možnost
změny UID, zpráva by tak měla být identifikována dvojicí UID a UID validity. Kromě situace, kdy dojde k přetečení UID a reorganizace identifikátorů zpráv je tak nezbytná, však
běžně dostupné servery UID validity nemění.)
Protože verze položek budou nést unikátní UID zpráv, musí být složka na IMAP serveru
po celou dobu vyhrazena pouze pro synchronizování jednoho lokálního adresáře (ke složce
samozřejmě přistupují klienti z různých zařízení, není však možné dovolit, aby byly do jedné
složky vkládány položky z více lokálních adresářů jednoho klienta, případně aby se do složky
ukládaly jiné zprávy než synchronizační).
3.1. ANALÝZA
3.1.3.4
15
Přesouvání starých verzí položek
Vlastností IMAP protokolu je i nemožnost zprávy na serveru editovat. Podporováno je pouze
jejich ukládání, odstranění, případně přesunutí. Změny v kontaktech tedy budeme ukládat
tak, že původní zpráva se smaže a do složky na server bude odeslána zpráva s novou verzí.
Tato zpráva získá unikátní UID, které se pro naše potřeby stane RevId. Pro uchovávání
historie je možné místo odstraňování starých zpráv přesouvání do složky např. Deleted.
Tuto složku bude uživatel moci později kdykoli vymazat.
3.1.4
GUI Thunderbirdu s ohledem na kontakty
Grafické rozhraní pro editaci kontaktů v programu Thunderbird je ukázáno na obrázku 3.1.
Protože součástí práce je rozšíření struktury kontaktů o další položky (atributy kontaktu),
je nutné upravit také toto rozhraní. Přidáné atributy se budou nejvíce týkat typování stávajících atributů (např. přidání možnosti specifikovat typ telefonu – mobilní, pracovní, domů
atd.). Jako inspirace v tomto ohledu poslouží grafické rozhraní zásuvného modulu gContactSync (viz obr. 2.3). Návrh takového okna je na obrázku B.1 v příloze tohoto dokumentu.
Obrázek 3.1: Grafické rozhraní editace kontaktu v Thunderbirdu 11.0.1
3.1.5
Mozilla Application Framework
Zásuvné moduly pro Mozilla Thunderbird stejně jako pro Mozilla Firefox mohou být vyvíjeny v prostředí Mozilla Application Framework. Tento framework postkytuje vývojářům
několik služeb pro jednodušší implementaci. Logika aplikace je psána v jazyce Javascript,
16
pro tvorbu grafického uživatelského rozhraní se využívá XUL technologie, je zde i možnost
využití cross-platformních objektových komponent přes technologii XPCOM. K Frameworku
existuje poměrně bohatá dokumentace, ač často se vztahuje již ke starším verzím. Je jí tedy
nutné brát často s rezervou a všechny implementační detaily ověřovat v nových verzích. Při
vývoji byla využita obecná příručka vývoje aplikací pro Mozilla Framework [7], článek o
vývoji zásuvných modulů do Mozilla a Thunderbird aplikací [8] a dále pak dokumentace z
oficiálních stránek pro podporu vývoje [9].
3.2
Návrh implementace
Pro pochopení následujícího návrhu architektury aplikace si dovolím odkázat nejprve na
následující kapitolu 4 věnovanou výhradně podrobnému popisu synchronizačního protokolu.
3.2.1
Struktura aplikace
Aplikace se bude skládat z následujících prvků: obecný synchronizační modul, rozšiřující
modul pro synchronizaci kontaktů, IMAP klient pro komunikaci se vzdáleným úložištěm a
grafické uživatelské rozhraní pro podporu rozšířených atributů kontaktů a tvorbu synchronizačních účtů.
3.2.1.1
Vrstvy synchronizačního modulu
Obecný synchronizační modul je navržen ve třech vrstvách, kde nejnižší vrstva (remote storage) obstarává komunikaci se vzdáleným úložištěm (získávání a ukládání zpráv), prostřední
vrstva (common sync) řídí synchronizační fáze a horní vrstva (items) slouží pro obsluhu položek v lokálním úložišti. Tyto vrstvy jsou naznačeny také v obrázku 3.2.
Obrázek 3.2: Návrh třívrstvé architektury
3.2. NÁVRH IMPLEMENTACE
3.2.1.2
17
Význam a úkoly jednotlivých vrstev
Horní vrstva je od obecné synchronizace oddělena, protože každý typ synchronizovaných
položek vyžaduje jiný přístup. Kontakty v e-mailovém klientu jsou uloženy jinde a za pomocí jiných objektů než události z kalendáře. Obecná obsluha synchronizace však na těchto
podrobnostech ohledně konkrétních položek nesmí záležet. Spodní vrstva je obecné synchronizace oddělena proto, abychom umožnili synchronizačnímu modulu jednoduše přidat i jiné
vzdálené úložiště než jen IMAP server.
Po vrstvě items je vyžadováno umožňovat načítání položek z lokálního úložiště (tvorba
synchronizační tabulky), manipulaci s položkami (jejich vytváření, editaci a odstraňování),
dále serializaci a deserializaci položek do zpráv. Pro různé druhy položek budou sloužit vždy
samostatné třídy vykazující zmiňované funkcionality. Po remote storage vrstvě se vyžaduje,
aby uměla procházet vzdálené úložiště, získávat z něj a zapisovat do něho zprávy (fáze
import, export a zamykání úložiště).
3.2.1.3
Implementace vrstev
Vstupní bod synchronizace bude v horní vrstvě. Voláme vždy synchronizaci konkrétního typu
položek (konkrétního adresáře s kontakty atd.). Z této vrstvy se bude volat třída implementující vrstvu obecné synchronizace, která bude již dále řídit jednotlivé fáze synchronizace.
Vrstva items bude implementována pro různé druhy položek samostatnými třídami. Metody, které musí tyto třídy implementovat, budou popsány dále. V aplikaci k synchronizaci
kontaktů bude konkrétně implementována třídou ContactSynchronization. Vrstva common sync bude implementována pomocí třídy CommonSync. Instance této třídy bude obsahovat objekty jako ukazatele na instance tříd implementujících nadřazenou a podřazenou
vrstvu, přes tyto objekty bude docházet k volání obslužných metod synchronizace. Vrstva
remote storage bude implementována pomocí třídy ImapSyncController s IMAP klientem
a třídy ImapSync, která tohoto klienta obsluhuje.
3.2.1.4
IMAP klient
Klient bude přes socket komunikovat se serverem, starat se o načtení aktuálních verzí položek, zápis nových verzí, přesouvání a odstraňování starých verzí. Při vývoji bude použita a
rozšířena IMAP knihovna Bc. Petra Macha, kterou implementoval v rámci bakalářské práce.
Protože IMAP knihovna je asynchronní, bude celý modul implementován jako flow mezi
metodami jednotlivých tříd. Objekty budou tedy pomocí scope vědět o objektech jejich
metodách, které mají po ukončení svého běhu volat. Přes scope se například do obsluhy
IMAP úložiště dostane odkaz na metodu, která se má zavolat po úspěšném načtení zpráv.
3.2.1.5
Zodpovědnost vrstev v jednotlivých fázích synchronizace
Za importní a exportní fázi je zodpovědná vrstva remote storage. Tato vrstva taktéž zodpovídá za bezchybné zamykání a odemykání vzdáleného úložiště. Odpovědnost za fázi synchronizačního jádra je rozdělena mezi zbývající dvě vrstvy. Common sync má na starost
pouze obecnou synchronizaci a to procházení synchronizační tabulky a verzování položek do
databáze. Pro vytvoření synchronizační tabulky a editaci položek vyžaduje funkce vrstvy
items.
18
3.2.2
Řešení kolizí
Aby uživatel mohl při kolizi pohodlně vybírat hodnoty položek, je navrženo zobrazování
těchto kolizí v samostatném okně aplikace. V okně budou v tabulce srovnány hodnoty
jednotlivých subatributů. Existuje-li rovnost alespoň ve dvou hodnotách, je do sloupce s
výsledkem rovnou předvybrána hodnota dle algoritmu slučování, takové řádky jsou pak
podbarveny zeleně. Neexistuje-li řešení podle algoritmu slučování, řádky jsou podbarveny
červeně. Návrh takového okna je v obrázku 3.3.
Obrázek 3.3: Návrh okna pro řešení kolizních situací
3.2.3
Formát přenášených objektů
Pro synchronizaci s ostatními klienty je nutné vytvořit jednotný formát přenášených zpráv
(serializovaných kontaktů). Po dohodě s vedoucím práce jsem se inspiroval projektem Portable Contacts [11], který modeluje kontakty jako JSON elementy [12]. Toto bude pro serializaci kontaktů velmi výhodné, protože mezi JSONy a objekty v Javascriptu je přímý vztah
– lze je mezi sebou nativně převádět. Serializace a deserializace kontaktů je tak elegantně
vyřešena.
3.2.4
Optimalita datového přenosu
Pro dosažení minimálního datového přenosu při synchronizaci bude každý klient ukládat
stav vzdáleného úložiště po každé sychronizaci. Jedná se o dvojici existingItems a nextUID,
19
tedy počet uložených zpráv a UID příští zprávy. Díky znalosti této dvojice můžeme lehce
předejít stahování objemných dat v případě, že se ve vzdáleném úložišti neprovedla žádná
změna. Pokud byla v době od poslední synchronizace nějaká položka ze vzdáleného úložiště odstraněna, musíme sáhnout ke stahování zpráv, abychom zjistili, o kterou položku
se jednalo. I tak je však cílem nestahovat verze položek celé, nýbrž jen jejich hlavičky. Pro
tento účel bude v hlavičce každé zprávy uloženo UUID sloužící k identifikaci kontaktů. Porovnáním stažených UUID z hlaviček s lokální verzí adresáře jednoduše zjistíme například,
který kontakt byl smazán. Teprve při zjištění, že na serveru se nachází nová verze položky
se přistoupí načtení jejího obsahu a přílohy.
3.2.5
Rozšíření atributů kontaktů
Následující odstavce se týkají návrhu rozšíření kontaktů o typy používané v OS Android.
Tento návrh je rozdělen na backend (ukládání těchto rozšířených typů) a frontend (zobrazování rozšířených typů v grafickém uživatelském rozhraní).
3.2.5.1
Backend
Vlastnosti kontaktu jsou v Thunderbirdu ukládány v instancích třídy nsIAbCard [9], která
bohužel postrádá možnost vylistování všech atributů kontaktu.
Pro získání hodnoty atributu kontaktu případně pro jeho editaci nabízí třída pouze
funkce getProperty a setProperty. Všechny atributy jsou typu string a tak změna se provádí
například voláním aCard.setProperty("FirstName","Karel");.
Aplikace si tedy bude muset pamatovat všechny přidané atributy pro jejich další používání (jejich změnu, či vyčištění kontaktu). Druhou možností by bylo vytvořit nad touto
instancí wrapper, který by ukládal atributy kontaktu do seznamu, přes který bychom mohli
listovat. Při tomto řešení by však bylo nutné přepsat kompletně funkce jádra Thunderbirdu
starající se o zobrazování položek kontaktů v grafickém rozhraní a jejich ukládání po editaci. Vzhledem k tomu, že rozšíření atributů v kontaktu není velké, navrhuji použít první
variantu.
Z instancí nsIAbCard budeme při každé synchronizaci vytvářet JSON (export kontaktu)
a opačně (import kontaktu). Toto budou mít na starost 2 funkce: importContactProperties
a exportContactProperties. Pro funkční serializaci aplikace bude muset znát i všechny defaultní atributy třídy nsIAbCard (kontakt neumí odstranit všechny svoje atributy). Editace
kontaktu se provede tak, že se nejdříve všechny jeho atributy odstraní (nastaví na prázdný
řetězec), pak teprve jsou nastaveny jeho atributy na nové hodnoty. Atributy (defaultní i
přidané) budou aplikaci dostupné přes globální objekt rozšíření.
Změny v atributech kontaktů budou následující:
∙ přidání typů k telefonním číslům,
∙ rozšíření počtu e-mailových adres,
∙ přidání typů k e-mailovým adresám,
20
∙ přidání typů k webovým stránkám,
∙ přidání IM účtů (uživatelské jméno, protokol, typ),
∙ přidání SIP účtů (uživatelské jméno, typ).
Hodnoty konkrétních typů budou převzaty z dokumentace k OS Android [10].
3.2.5.2
Frontend – GUI
Po rozšíření atributů kontaktu je nutné změnit i grafické rozhraní starající se o zobrazování
kontaktů tak, aby k těmto přidaným atributům měl uživatel přístup. K novým atributům budou namapovány ovládací prvky podle návrhu v obrázku B.1. O grafické uživatelské
rozhraní kontaktů se v Thunderbirdu starají XUL objekty abEditCardDialog.xul a abNewCardDialog.xul. Jejich volání bude překryto pomocí overlay tak, aby se při otevírání okna
s kontaktem otevřel současně i soubor cardDialogOverlay.xul, který bude zajišťovat přidání
elementů DOM stromu tohoto okna. Ovládací elementy se nejprve v .xul souboru nadefinují, následně bude implementována jejich obsluha (ukládání, přípustné hodnoty). Overlay
se vloží do souboru chrome.manifest, což je zaváděcí soubor zásuvného modulu do hostitelské aplikace. Tím je zajištěn vstup souborů s objekty starajícími se o zobrazování a ukládání
přidaných kontaktních atributů do jádra Thunderbirdu. Toto překrytí implicitních souborů
je ukázáno zde:
overlay chrome://messenger/content/addressbook/abEditCardDialog.xul
chrome://sync.extbrain.thunderbird/content/gui/cardDialogOverlay.xul
overlay chrome://messenger/content/addressbook/abNewCardDialog.xul
chrome://sync.extbrain.thunderbird/content/gui/cardDialogOverlay.xul
3.2.6
Použité nástroje
Pro vývoj zásuvného modulu budou použity následující nástroje:
IntelliJ IDEA
Pro psaní javascriptového kódu lze použít samozřejmě jakýkoli textový editor. Idea však
poskytuje dobré zvýrazňování syntaxe, podporu refaktoringu a našeptávání ze standardních
knihoven, tak z kódu vlastního projektu.
Venkman
Debugovací nástroj přímo jako zásuvný modul v Mozilla Thunderbird umožňuje pozastavit
vykonávání kódu přímo v aplikaci. Dobře použitelný při zobrazování obsahu proměnných,
také pro prozkoumávání zdrojových souborů jádra Thunderbirdu.
21
DOM Inspector
Umožňuje prozkoumávání hierarchického stromu Document Object Model elementů v grafickém rozhraní. Užitečný hlavně při potřebě navázat na defaultní GUI novými ovládacími
prvky.
SQLite Manager
Nástroj pro kompletní management databáze SQLite, která je součástí Mozilla Thunderbird.
Zobrazení struktury jednotlivých tabulek včetně jejich obsahu usnadňuje ladění a optimalizaci databázových dotazů.
22
Kapitola 4
ExtBrain Sync Protokol
Pro bezchybné realizování synchronizace je nutné definovat nejen formát zpráv, které budou
přenášeny, a typ úložiště, ale obecněji i protokol, podle kterého se bude řídit jednak komunikace klientské aplikace se vzdáleným úložištěm, ale i sled kroků prováděných nad lokálním
úložištěm. Na podrobný popis protokolu se zaměřuje následující kapitola.
4.1
Definice pojmů
Označme entitu určenou k synchronizaci jako položku (item). Položkou může být například
množina kontaktních informací, událost v kalendáři apod. Především při synchronizačním
přenosu lze místo pojmu položka užívat označení zpráva. Zpráva se skládá povinně z těla
(content) a nepovinně přílohy (attachment). Content je serializovaná položka v určitém
formátu (např. XML, JSON), má podobu textových dat. Attachment je soubor, který se
k položce váže. Může mít podobu textového nebo binárního souboru. Jedná se například
obrázek přiložený ke kontaktu. Účtem označujeme souhrn informací o synchronizovaném
lokálním adresáři, uživatelské jméno, adresu serveru, port, typ zabezpečení a název složky
na serveru. Synchronizace je jednorázová akce vyvolaná uživatelem či automaticky vedoucí
k dosažení stavu, kdy sobě obsahem a strukturou odpovídají položky v lokálním adresáři a
ve vzdáleném úložišti.
4.2
Označení položky
Položka je identifikována pomocí UUID (Universally Unique IDentifier) obsaženého v těle
zprávy. Synchronizačním protokolem je zajištěno, že se v úložišti v jednu chvíli nevyskytují
dvě zprávy se stejným UUID. Protokol přikládá každé verzi položky také unikátní RevId,
které slouží k rychlému odlišení verzí. Unikátnost tohoto identifikátoru je zaručena pomocí
IMAP protokolu.
23
24
KAPITOLA 4. EXTBRAIN SYNC PROTOKOL
4.3
Lokální a databázové úložiště
Lokální úložiště (adresář) je místo na lokálním zařízení (počítači, mobilním telefonu), které
má být synchronizováno se vzdáleným úložištěm. Pro podporu synchronizace slouží databázové úložiště uchovávájící informace o verzích položek. Databáze zajišťuje uchovávání těchto
informací o každé položce: UUID, RevId, tělo, hash přílohy, entryPresent (zdali položka v
lokálním úložišti existuje, nebo byla smazána) a účet, ke kterému se položka váže.
4.4
Vzdálené úložiště
Jako vzdálené úložiště synchronizace slouží složka (mailbox) v e-mailovém účtu na IMAP
serveru. Zprávy jsou do úložiště posílány pomocí IMAP protokolu dle RFC 3501. Zpráva je
pro tento přenos zabalena do IMAP zprávy dle RFC 822 (viz odstavec 3.1.3), ta je pomocí
příkazu APPEND uložena na server. RevId je v ExtBrain Sync protokolu označení pro
UID IMAP zprávy, které je IMAP protokolem vygenerováno vždy při vložení zprávy do
složky. IMAP zpráva obsahuje kromě jiných standardních hlaviček i řádek s UUID položky.
ExtBrain Sync protokol vyžaduje v hlavičce pouze tuto UUID položku, pro přehlednost jsou
však v IMAP zprávách ponechány i standardní hlavičky.
Ukázka hlavičky IMAP zprávy rozšířené o UUID záznam:
1
2
3
4
5
6
7
8
9
From: Archimedes Thunderbird testProfile <[email protected]>
Date: Tue, 03 Apr 2012 10:02:40 GMT
Subject: =?UTF-8?Q?Karel Jan=C3=A1k?=
To: [email protected]
uuid: d10a7f70-3a97-4ac9-8293-b0de38c95a3d
Message-Id: <ed4f2786b2284cbfb037291584f49393@libimap-client>
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
V následujících podkapitolách jsou podrobně popsány jednotlivé fáze synchronizace. Začneme popisem výměny synchronizačních zpráv, na konci kapitoly je pak popsán způsob
zajištění unikátního přístupu do vzdáleného úložiště.
4.5
Fáze synchronizace
Proces synchronizace je možné rozdělit do tří hlavních fází (viz obr. 4.1).
Ve fázi import se kontaktuje vzdálené úložiště, zjišťuje se jeho aktuální stav a podle potřeby se z něj získají aktuální/nová data. Druhou fází (označenou jako core) je porovnávání
příchozích změn se stavem lokálních položek, jejich editace a případné vybrání pro závěrečnou fázi – export. V té se do vzdáleného úložiště ukládají změny, případně se odstraňují staré
verze položek. Není-li třeba měnit obsah vzdáleného úložiště, je fáze export vynechána.
4.6. FÁZE IMPORT
25
Obrázek 4.1: Fáze procesu synchronizace
4.6
Fáze import
Cílem této fáze je zjištění obsahu složky v e-mailové schránce. Data jsou předána dále ke
zpracování synchronizačnímu jádru. Získávání obsahu složky se děje ve třech krocích tak,
aby se minimalizoval datový přenos mezi klientskou aplikací a serverem.
Postup v této fázi je možné popsat jako sled těchto kroků:
1. získání UIDNEXT a EXISTS,
2. načtení hlaviček IMAP zpráv,
3. načtení těl a příloh nových zpráv.
Průběh kroků ve fázi import ukazuje také obrázek 4.2.
IMAP protokol udržuje nad složkou několik atributů, pro ExtBrain Sync protokol jsou
důležité následující dva: UIDNEXT a EXISTS. První označuje předpokládané UID příští
zprávy, která bude do složky uložena. Je-li UIDNEXT vyšší než bylo při poslední synchronizaci, do složky byla uložena nová zpráva. Změna tohoto atributu však označuje pouze
ten fakt, že zpráva s daným UID byla do složky přidána. Z pouhé změny UIDNEXT nelze
rozhodnout, zda tato zpráva ve složce stále existuje. Počet zpráv ve složce označuje druhý
parametr – EXISTS. Klientská aplikace musí zajistit lokální uložení obou těchto atributů
při každé synchronizaci. Tato dvojice se souhrnně označuje jako „stav účtu“.
Aby se nemusel získávat obsah všech zpráv ve složce, není-li to nezbytně nutné, v prvním
kroku se zjistí hodnoty UIDNEXT a EXISTS. Pokud se obě tyto hodnoty rovnají hodnotám
z předchozí synchronizace, ve vzdálené složce nedošlo k žádným změnám a není proto nutné
obsah úložiště dále načítat. (Protože IMAP zprávy na serveru není možné editovat, je zajištěno, že zprávy se stávajícím UID mají stejný tvar, jako při odesílání klientem. Z této situace
26
Obrázek 4.2: Stavový diagram fáze import
lze vyvodit závěr, že aktuální klientská aplikace byla poslední, která ve vzdáleném úložišti
prováděla změny.) Liší-li se alespoň jedna z hodnot, je nutné přistoupit ke druhému kroku,
kterým je načtení hlaviček IMAP zpráv. Pokud se stav účtu liší v UIDNEXT a zprávy s
vyšším nebo rovným UID než je lokální UIDNEXT ve složce na serveru existují, je nezbytné
získat jejich kompletní obsah, což je zároveň třetím a záverečným krokem této fáze.
V následujících odstavcích je podrobnější popis kroků prováděných ve fázi import.
4.6.1
Získání UIDNEXT a EXISTS
Atributy složky UIDNEXT a EXISTS se vyskytují v odpovědi IMAP serveru na příkaz
SELECT (vybrání složky pro přístup ke zprávám uvnitř). Požadované atributy se tedy získají jednorázovým zavoláním příkazu SELECT s parametrem názvu složky a vyparsováním
hodnot pomocí regulárních výrazů.
Ukázka získání atributů UIDNEXT a EXISTS je v následujícím výpisu. Řádek 1 obsahuje příkaz klientské aplikace, další řádky odpověď serveru. Řetězec a003 před příkazem je
tzv. tag umožňující identifikovat odpověď serveru na daný příkaz při asynchronních voláních.
V tomto případě je vybrána složka „extbrainContacts“, hodnota UIDNEXT je rovna 988 a
ve složce existuje 5 zpráv.
1
2
3
4
5
a003 SELECT extbrainContacts
* FLAGS (\Answered \Flagged \Draft \Deleted \Seen, Seen Test lock)
* OK [PERMANENTFLAGS (\Answered \Flagged \Draft \Deleted \Seen,
Seen Test lock \*)] Flags permitted.
* OK [UIDVALIDITY 660858846] UIDs valid.
4.6. FÁZE IMPORT
6
7
8
9
27
* 5 EXISTS
* 0 RECENT
* OK [UIDNEXT 988] Predicted next UID.
a003 OK [READ-WRITE] extbrainContacts selected. (Success)
4.6.2
Načtení hlaviček IMAP zpráv
Příkaz FETCH slouží v protokolu IMAP k získávání zpráv. Příkaz vyžaduje dva parametry:
číselné označení sekvence požadovaných zpráv a vyžadované prvky zprávy (např. jen některé položky hlavičky, tělo, přílohu). UID FETCH má stejné použití, jen se jako parametr
označující sekvenci získávaných zpráv udává UID zprávy namísto pořadí zprávy ve složce.
Hlavičky zpráv získáme jednorázovým odesláním příkazu UID FETCH s parametrem pro
získání všech zpráv (UID zpráv 1 až *) a BODY[HEADER.FIELDS (UUID)] pro získání UUID
řádku z hlavičky IMAP zprávy.
Ukázka komunikace klienta se serverem pro získání hlaviček IMAP zpráv.
1
2
3
4
5
6
7
8
9
10
11
12
a004 UID FETCH 1:* BODY[HEADER.FIELDS (UUID)]
* 1 FETCH (UID 892 BODY[HEADER.FIELDS (UUID)]
uuid: e0be92ae-1a96-4d74-a4f3-1aca8936fdf6)
uuid: 2906f0f4-4958-4be4-904a-b80f4af3ceeb)
uuid: d86d2e79-0f4b-4504-822f-b7529d7d8bf6)
uuid: c6d7c601-a11c-46fb-b96c-733f9c6a9dd9)
uuid: 6ace5e74-97a1-4502-9b56-069caa33485c)
a004 OK Success
{46}
{46}
{46}
{46}
{46}
Z odpovědi serveru (řádky 2 – 12) je vytvořen seznam položek ve tvaru <UUID : RevId>
(RevId=UID zprávy). Příklad takové struktury vytvořené z předchozí odpovědi serveru je
v tabulce 4.1.
UUID
e0be92ae-1a96-4d74-a4f3-1aca8936fdf6
2906f0f4-4958-4be4-904a-b80f4af3ceeb
d86d2e79-0f4b-4504-822f-b7529d7d8bf6
c6d7c601-a11c-46fb-b96c-733f9c6a9dd9
6ace5e74-97a1-4502-9b56-069caa33485c
RevId
892
910
915
923
987
Tabulka 4.1: Načtení hlaviček IMAP zpráv - výsledek
28
4.6.3
Načtení těl a příloh nových zpráv
Nové zprávy (nově přidané od poslední synchronizace) jsou ty, které mají v tabulce hlaviček
RevId vyšší nebo rovno lokálnímu UIDNEXT. Tyto zprávy je na rozdíl od ostatních nutné
získat celé, k tomu se využije opět příkazu UID FETCH. Po serveru požadujeme celé tělo
zprávy, proto jako druhý parametr použijeme BODY[TEXT].
Příkaz na získání zprávy s RevId 923 z tabulky 4.1 tak bude vypadat takto: UID FETCH
923:923 BODY[TEXT]. Ukázka komunikace nutné k získání této zprávy je zde:
1
2
3
4
5
a005 UID FETCH 923:923 BODYTEXT
* 5 FETCH (UID 65 FLAGS (\Seen) BODYTEXT {451}
--e0cb4efe319222759c04bd6bef7a
6
7
8
{"name":"Karel Pol=C3=A1=C5=A1ek","uuid": "c6d7c601-a11c-46fb-b96c-733f9=
c6a9dd9"}
9
10
11
12
13
14
--e0cb4efe319222759c04bd6bef7a
Content-Type: image/png; name="karel.png"
Content-Disposition: attachment; filename="karel.png"
Content-Transfer-Encoding: base64
X-Attachment-Id: f_h0wr2yuw0
15
16
17
18
b2JyYXplaw==
--e0cb4efe319222759c04bd6bef7a--)
a005 OK Success
V řádku 1 je příkaz klientské aplikace včetně úvodního tagu. Řádky 7 a 8 obsahují tělo
zprávy, řádek 16 base64 reprezentaci souboru s názvem karel.png v příloze.
Tělo zprávy obsahuje serializovanou podobu synchronizované položky. Tělo zprávy a příloha jsou přidány do odpovídajícího řádku seznamu z předchozí sekce. Tento seznam položek
nyní již ve tvaru <UUID : RevId, content, attachment> je výstupem tohoto kroku a je
předán dále synchronizačnímu jádru. Ukázka této struktury je v tabulce 4.2. V řádku s RevId 923 vidíme tělo zprávy a přílohu tak, jak byly přijaty v tomto kroku. Poté byla získána
ještě zpráva s RevId 987, ta přílohu neobsahuje.
4.7
Synchronizační jádro
Úkolem této ústřední fáze procesu synchronizace je učinit všechny „lokální“ kroky potřebné
pro nastolení konzistentního stavu mezi vzdáleným úložištěm a místním adresářem. To zahrnuje práci s lokálními položkami (vyhledání změn, serializace), vytvoření synchronizační
tabulky, její procházení a vykonávání editací položek, přípravu položek pro exportní fázi
(odeslání položek, či jejich odstraňění).
Kroky synchronizačního jádra ukazuje obrázek 4.3.
4.7. SYNCHRONIZAČNÍ JÁDRO
UUID
e0be92ae...
2906f0f4...
d86d2e79...
c6d7c601...
RevId
892
910
915
923
6ace5e74...
987
content
{"name":"Karel
Polášek","uuid":
"c6d7c601-a11c-46fb-b96c733f9c6a9dd9"}
{"name":"Jakub Nový","uuid": "6ace5e7497a1-4502-9b56-069caa33485c"}
29
attachment
karel.png
Tabulka 4.2: Načtení těl IMAP zpráv - výsledek
Obrázek 4.3: Stavový diagram jádra synchronizace
V následujících dvou podkapitolách se zaměříme na popis kroků v synchronizačním jádru.
Ty jsou dva: vytvoření synchronizační tabulky a její následné procházení.
4.7.1
Vytvoření synchronizační tabulky
Základem synchronizační tabulky jsou data získaná z předchozí fáze import. Tento krok
má za úkol přidat verze položek v lokálním adresáři a verze z databáze. Cílem je vytvoření struktury podobné tabulce 3.1. Místo pouhých čísel revizí budou však v této struktuře
textové reprezentace verzí, toho je zapotřebí pro řešení kolizí v dalším kroku. Protože číslo
RevId je lokálním položkám přidělováno až prostřednictvím IMAP protokolu při uložení
na server, jsou lokální položky zastoupeny pouze textovou reprezentací verze. Hotovou synchronizační tabulku pro příklad z předchozí fáze ukazuje tabulka 4.3. Attachment je místo
názvu souboru převeden na hash. UUID a content jsou pro účel této tabulky zkráceny.
Inicializace seznamu položek z databáze
Skončila-li fáze import po kroku 1 (získání UIDNEXT a EXISTS) bez vytvoření seznamu
položek a není tudíž seznam položek inicializován, je nutné jej vytvořit nyní. Pokud seznam
30
row
1
remote
UUID RevId content
e0be
892
2
2906
910
3
d86d
915
4
c6d7
923
5
6ace
987
6
186a
Karel
Polášek
Jakub
Nový
hash
1231
database
RevId content
892
Pavel
Stejný
910
Tomáš
Změna
915
Jan
Starý
914
Karel
Poláczek
913
hash
1231
Josef
Smazaný
local
content hash
Pavel
Stejný
Tomáš
7323
Změna
Karel
Poláček
1231
Josef
Smazaný
Tabulka 4.3: Synchronizační tabulka - hodnoty mají ilustrační charakter (UUID a content
jsou zkráceny, hash je výsledek hashovací funkce zavolané na soubor v příloze)
nebyl vytvořen, znamená to, že se ve vzdáleném úložišti nevyskytují změny, a tak je možné
vytvořit obraz tohoto seznamu lokálně pomocí výběru položek z databáze. Pro tento účel
slouží atribut entryPresent, který je v databázi uložen pro každou položku. Při vytváření
obrazu položek ve vzdáleném úložišti vybíráme z databáze právě ty položky, které mají
atribut entryPresent nastaven na true. S tímto seznamem položek pak lze pracovat stejně
jako by byl získán ze vzdáleného úložiště ve fázi import.
Přidávání verzí do tabulky
Následující popis přidávání verzí do tabulky se vztahuje k tabulce 4.3.
Při vytváření tabulky je nejprve nutné k položkám získaným ze serveru přidat verze
z lokálního adresáře a z databáze (řádky 1, 2, 4). Za databázovou verzi je považována verze
s nejvyšším RevId pro danou položku. Poté se přidávají všechny lokální položky, které ve
struktuře z fáze import chybí - byly ze serveru odstraněny (řádek 6). Nakonec se porovnává
stav lokálního adresáře s databází přes atribut entryPresent a přidávají se položky, které
byly lokálně od poslední synchronizace smazány (hledají se takové, které mají v databázi
entryPresent==true, ale v adresáři neexistují, řádek 3). Do řádku 5 nebyly přidány žádné
údaje, položka není v lokálním adresáři ani v databázi zastoupena.
Absence těla zprávy a hashe ze vzdáleného úložiště je v řádcích 1 až 3 dána tím, že nebyly
stahovány celé zprávy, ale pouze hlavičky obsahující UUID a RevId. Pomocí parametrů
UIDNEXT a EXISTS je zaručeno, že obsah zprávy není nutné stahovat ze serveru, protože
jej lze jednodušším způsobem získat z databáze. Protokolem je zajištěno, že databáze pro
tyto položky verze s danými RevId obsahuje, jak lze vidět ve sloupci database u těchto
řádků.
4.7.2
31
Procházení synchronizační tabulky
V tomto kroku synchronizace dochází k průchodu synchronizační tabulkou, manipulaci s
položkami a přípravou pro zapsání nových verzí do vzdáleného úložiště.
Před vyhodnocováním změn v hodnotách jednotlivých verzí se podívejme na každý řádek z globálního pohledu a rozlišujme mezi situacemi, kdy položka v jednotlivých úložištích
existuje, či nikoli. Situace, které mohou z tohoto úhlu pohledu nastat, lze popsat pomocí binárních řetězců. Máme tři možná úložiště, verze v daném úložišti je zastoupena (označme 1),
nebo chybí (0). Z toho plyne, že nastává celkem 23 = 8 možných situací, které můžeme nejprve rozlišit. Seřadíme-li úložiště například v pořadí remote, database, local, lze situace
označit pomocí binárních řetězců vzestupně od 000 po 111.
Některé ze situací však nejsou „platné“. Například situace označená jako 000, kdy položka
není v žádném z úložišť, nemůže nastat, neboť by se tak neměla jak dostat do synchronizační
tabulky. Obdobně je tomu se situací označenou jako 010, kdy je položka zastoupena pouze
v databázi. To by znamenalo, že položka existovala ve vzdáleném a lokálním úložišti a byla
odtud odstraněna. (Při odstranění se však příznak položky entryPresent v databázi nastaví
na false a položka se při dalším vytváření synchronizační tabulky ignoruje.) Všechny ostatní
situace označené binárními řetězci jsou platné, nejkomplexnější je samozřejmě situace 111,
kdy jsou verze dané položky zastoupeny ve všech úložištích. Touto situací, pro jejíž vyřešení
potřebujeme znát již konkrétní hodnoty verzí se budeme zabývat později. Všechny situace,
které mohou nastat jsou včetně popisu v tabulce 4.4.
remote
0
0
0
0
1
1
1
1
database
0
0
1
1
0
0
1
1
local
0
1
0
1
0
1
0
1
popis situace
neplatné
nová lokální položka
neplatné
položka ve vzdáleném úložišti smazána
nová položka ve vzdáleném úložišti
účet odstraněn a vytvořen nový, položka ponechána
položka v lokálním úložišti smazána
nelze takto rozhodnout
Tabulka 4.4: Možné situace v synchronizační tabulce (1 označuje prezenci verze, 0 absenci,
popis označuje, co se stalo od poslední synhronizace)
Popis algoritmu průchodu tabulkou
Průchod tabulkou lze nejlépe popsat přímo pseudokódem, jeho zápis je v algoritmu 4.1. Z
důvodů zjednodušení je v algoritmu vynecháno řešení specifického případu, který bychom
mohli označit jako situace 101. Ta znamená, že položka chybí pouze v databázi. Toto se
může při spoléhání na fakt, že neexistují dvě různé položky se stejným UUID, stát pouze v
situaci, kdy jsou databázová data odstraněna bez odstranění položek v lokálním a vzdáleném
úložišti.
32
Algoritmus je realizován jako for cyklus, v němž se prochází přes všechny položky v
tabulce. Uvnitř for cyklu jsou nejprve umístěny 4 podmínky zjišťující prezenci a absenci
položek v jednotlivých lokacích – vzdálené, lokální úložiště a databáze (řádky 2 až 17).
Splňuje-li položka určitou podmínku, je vyvolána akce přidružená k dané situaci a pomocí
continue se ukončí běh for cyklu pro tuto položku. Tato úvodní sada podmínek zahrnuje
situace, kdy položka je na lokální nebo vzdálené straně nově vytvořena, případně odstraněna.
Nesplňuje-li položka ani jednu z podmínek, znamená to, že v tabulce existují verze pro
všechna úložiště. Manipulace s položkou už tedy nebude pouze v mezích „vytvoř novou“,
případně „smaž“, bude se jednat o přepis verze položky.
Pro další postup je nutné zjistit, zdali byla položka v lokálním adresáři změněna. K
tomu slouží podmínka na porovnání databázové a lokální verze (od řádku 18 po 33). Tato
podmínka se dále větví a je rozkreslena na obrázku 4.4.
Obrázek 4.4: Poslední krok průchodu synchronizační tabulkou (v algoritmu 4.1 řádky 18 až
33)
Neliší-li se databázová a lokální verze, položka změněna nebyla a můžeme tedy přijmout
změnu. Pokud se liší (položka byla změněna), porovnají se ještě RevId z databáze a ze
vzdáleného úložiště. Rovnají-li se RevId, bude lokální verze (změna) zapsána na server,
nerovnají-li se, došlo k situaci, kdy byla změna položky provedena jednak v lokálním, tak ve
vzdáleném úložišti a dochází ke kolizi. Při obsluze kolize je doporučeno zkontrolovat, zdali
není lokální a vzdálená verze obsahem stejná. Více o kolizích a jejich řešení je v podkapitole
Princip synchronizace.
33
Algoritmus 4.1 procházení synchronizační tabulky
1: for all item in syncTable do
000 neplatné
001:
2:
if ( !item.remote && !item.database && item.local ) then
3:
objectsToExport.push(item);
◁ položka vybrána pro export
4:
continue;
5:
end if
010 neplatné
011:
6:
if ( !item.remote && item.database && item.local ) then
7:
deleteLocal(item);
◁ smazat položku lokálně
8:
continue;
9:
end if
100:
10:
if ( item.remote && !item.database && !item.local ) then
11:
createLocal(item);
◁ vytvoření nové lokální položky
12:
continue;
13:
end if
101: vynechána
110:
14:
if ( item.remote && item.database && !item.local ) then
15:
objectsToDelete.push(item);
◁ položka vybrána pro smazání
16:
continue;
17:
end if
111:
18:
if ( equals( item.local, item.database ) ) then
◁ verze se sobě rovnají
19:
20:
21:
22:
23:
24:
25:
26:
27:
28:
29:
30:
31:
32:
33:
34:
if ( item.remote.RevId > item.database.RevId ) then
editLocalEntry(item);
◁ změň lokální položku
continue;
end if
continue;
◁ všechny verze se rovnají, nedělej nic
else
◁ verze se sobě nerovnají
if ( item.remote.RevId == item.database.RevId ) then
objectsToExport.push(item);
◁ položka vybrána pro export
continue;
end if
if ( item.remote.RevId > item.database.RevId ) then
handleCollision(item);
continue;
end if
end if
end for
◁ kolize
34
Všimněme si také řádku 23 a příkazu continue hned za předchozí podmínkou. K vykonání tohoto příkazu dojde tehdy, není-li položka lokálně ani vzdáleně změněna (remote.RevId
== database.RevId) a není proto potřeba s ní nijak manipulovat. Za připomenutí stojí, že
protokolem je zajištěno, že nedojde k situaci, kdy remote.RevId < database.RevId. Podmínky na tyto situace jsou tedy vypuštěny.
Příklad průchodu konkrétní tabulkou
Pro příklad z předchozích odstavců by průchod tabulkou 4.3 vypadal následovně:
1. řádek: UUID e0be má zastoupení ve všech lokalitách, ve všech ve stejné verzi, tudíž splní
podmínku algoritmu průchodu tabulkou z řádku 18. I RevId se rovnají, proto se
podle řádku 23 s touto položkou manipulovat nebude.
2. řádek: UUID 2906 má taktéž zastoupení ve všech lokalitách, lokální však obsahuje kromě
těla položky i hash přílohy a tím se liší od verze v databázi. Tato položka tedy
nesplní podmínku v řádku 18. RevId vzdálené a databázové verze se shodují, proto
bude v řádku 26 vybrána pro export do vzdáleného úložiště.
3. řádek: UUID d86d má zastoupení pouze ve sloupci remote a database, v lokálním úložišti tedy neexistuje a to je známka toho, že odsud byla odstraněna. Po splnění
podmínky v řádku 14 bude vybrána pro smazání ve vzdáleném úložišti.
4. řádek: UUID c6d7 je zastoupeno ve všech třech lokalitách. Všimněme si, že ale pokaždé
v jiné verzi. Původní jméno „Karel Poláczek“ bylo lokálně upraveno na „Karel
Poláček“, zatímco ve vzdáleném úložišti na „Karel Polášek“. Hashe příloh se neliší, příloha změněna nebyla. Položka tedy byla od poslední synchronizace lokálně
změněna, navíc byla načtena v nové verzi ze vzdáleného úložiště, nesplní tedy
porovnávací podmínku v řádku 18. RevId ze vzdáleného úložiště je vyšší než z
databáze a proto nastává kolize.
5. řádek: UUID 6ace je obsaženo pouze ve sloupci remote, což znamená, že nebylo klientem
ještě registrováno. Položka splní podmínku v řádku 10 a bude tak lokálně nově
vytvořena. Zároveň s tím bude do databáze přidán tento záznam (hodnoty jsou
opět v plném tvaru, content a UUID vzato z tabulky 4.2):
UUID
RevId
content
:
:
:
hash
entryPresent
:
:
6ace5e74-97a1-4502-9b56-069caa33485c
987
{"name":"Jakub Nový","uuid": "6ace5e74-97a1-4502-9b56069caa33485c"}
true
6. řádek: UUID 186a je zastoupeno pouze ve sloupcích local a database. Ze vzdáleného
úložiště tedy musela být tato položka jiným klientem odstraněna. Položka splní
podmínku v řádku 6 a bude lokálně odstraněna. Po odstranění se u databázové
verze položky (RevId 913) nastaví atribut entryPresent na false.
35
Zápis verzí do databáze
Při průchodu se provádějí také zápisy verzí do databáze, ale pouze u položek, jejichž lokální
verze je přepisována verzí ze vzdáleného úložiště. U těchto verzí je totiž již znám atribut verze
RevId. U položek, které byly změněny lokálně a budou exportovány se zápis do databáze
provádí až po zapsání do vzdáleného úložiště – po přidělení RevId IMAP protokolem. Při
vkládání nové verze do databáze se musí zabezpečit nastavení atributu entryPresent na false
u předchozí verze. Taktéž musí být tento atribut změněn při odstranění položky.
Příprava pro exportní fázi
Vybrání položky pro exportní fázi procesu synchronizace je realizováno jako přidání do
struktury objectsToExport případně objectsToDelete. Výstupem synchronizačního jádra
jsou tedy tyto dva objekty. Jsou-li oba tyto objekty prázdné, synchronizace je ukončena
a k fázi export se nepřistupuje.
Ukázka výstupu pro náš příklad je v tabulkách 4.5 a 4.6. Všimněme si druhého řádku
objectsToExport s položkou, která vyvolala kolizi. Uživatel ji vyřešil tak, že dal v atributu
jméno přednost lokální verzi (Karel Poláček) a od položky odstranil přílohu.
objectsToExport:
remote
UUID RevId content
2906
910
c6d7
923
Karel
Polášek
hash
1231
database
RevId content
910
Tomáš
Změna
914
Karel
Poláczek
hash
1231
local
content hash
Tomáš
7323
Změna
Karel
Poláček
Tabulka 4.5: Příklad struktury objektu objectsToExport
objectsToDelete:
remote
UUID RevId content
d86d
915
hash
database
RevId content
915
Jan
Starý
hash
local
content hash
Tabulka 4.6: Příklad struktury objektu objectsToDelete
36
4.8
Fáze export
Fáze export má za úkol využít protokol IMAP k zapsání nových verzí položek na vzdálené
úložiště a odstranění (resp. přesunutí) starých, pokud je toho při synchronizaci zapotřebí.
Využívá k tomu struktur přicházejících od synchronizačního jádra, těmi jsou verze položek
srovnané v objektech objectsToExport a objectsToDelete. Protože IMAP protokol neumožňuje zprávy na serveru editovat, musí se nové verze položek na server uložit a staré verze
přesunout do jiné složky. Přesouvat se budou nejen položky z objectsToDelete, ale i položky
z objectsToExport, které obsahují záznam ve sloupci remote. V našem příkladu v tabulce
4.5 to jsou všechny položky. Je však nutné mít na paměti, že pokud by některá z položek
byla v lokálním úložišti nově vytvořena, byla by na server pouze zapsána bez následného
přesouvání předchozí verze, ta ostatně ani neexistuje.
Pro uchovávání historie nejsou zprávy ze serveru trvale odstraňovány, jsou pouze přesunuty do podsložky „Deleted“. Pro další synchronizace však nejsou tyto verze potřebné a tak
při nutnosti uvolnit místo na serveru mohou být z této složky kdykoli odstraněny.
Fázi export lze rozdělit do dvou navazujících kroků: krok zápisu a krok přesouvání. V
obrázku 4.5 označeno jako APPEND a MOVE. Je-li objectsToExport prázdný, přikračuje
se rovnou ke kroku přesování.
Obrázek 4.5: Stavový diagram fáze export
4.8. FÁZE EXPORT
4.8.1
37
Krok zápisu
Zápis položky na server je realizován pomocí IMAP příkazu APPEND se dvěma povinnými
parametry: složkou a obsahem zprávy (hlavička, tělo a příloha). K tělu a příloze položky
tedy musí být vygenerována standardní IMAP hlavička rozšířená o UUID záznam. Ukázka
této rozšířené hlavičky je v podkapitole Vzdálené úložiště. Do těla IMAP zprávy je vložena
serializovaná podoba těla položky, případná příloha je ve formátu base64. Jako tělo položky
je vždy brána lokální verze, to je ostatně přesně účelem tohoto kroku, exportovat lokální
verze.
Ukládání zpráv probíhá postupně po jedné položce procházením přes pole objectsToExport. Ve stavovém diagramu je to naznačeno cyklem kolem stavu APPEND. Odpověď
serveru na příkaz APPEND obsahuje UID nově přidané zprávy. UID je od této chvíle RevId
této verze položky a je spolu s tělem položky a hashem přílohy zapsáno do databáze.
Příklad
Komunikace mezi klientem a serverem během zápisu jedné IMAP zprávy je ukázána v následujícím výpisu. V něm se zapisuje položka z druhého řádku objectsToExport (tabulka
4.5). Řádek 1 obsahuje příkaz klienta, číslo 817 označuje délku zprávy ve znacích. Následuje hlavička zprávy (řádky 2 až 9). Na řádcích 15 a 16 je vidět serializované tělo položky
(tentokrát opět v nezkráceném tvaru, je uveden celý JSON včetně UUID položky), přílohu
položka neobsahuje, proto je vynechána. Poslední řádek ukazuje standardní odpověď klienta
na takový příkaz. Za APPENDUID je nejdříve uvedeno UIDVALIDITY a pak UID zprávy.
Toto UID se stane novým RevId této položky.
1
2
3
4
5
6
7
8
9
a006 APPEND extbrainContacts {817}
From: Archimedes Thunderbird testProfile <[email protected]>
Date: Fri, 13 Apr 2012 18:56:37 GMT
Subject: =?UTF-8?Q?Karel Pol=C3=A1=C4=8Dek?=
To: Imap Test <[email protected]>
uuid: 18c34b9c-d4fb-4ff3-b4d4-3d7aaf64c522
Message-Id: <da40e5efa35f40079a82b423f8ac2409@libimap-client>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary=a5a5fd7524ac42f5a61b434e568f7deb
10
11
12
13
--a5a5fd7524ac42f5a61b434e568f7deb
14
15
16
17
18
{"name":"Karel Pol=C3=A1=C4=8Dek","uuid":"c6d7c601-a11c-46fb-b96c-73=\r\n
3f9c6a9dd9"}
--a5a5fd7524ac42f5a61b434e568f7deb-a006 OK [APPENDUID 660858846 988] (Success)
Verzi položky bylo tedy přiděleno RevId s hodnotou 988, ihned po zapsání zprávy do vzdáleného úložiště je do databáze přidán záznam o nové verzi položky.
38
UUID
RevId
content
:
:
:
hash
entryPresent
:
:
18c34b9c-d4fb-4ff3-b4d4-3d7aaf64c522
988
{"name":"Karel Poláček",
"uuid": "18c34b9c-d4fb-4ff3-b4d4-3d7aaf64c522"}
true
Zároveň je u předchozí verze položky (RevId 914 viz tabulka 4.3) nastaven atribut entryPresent na false.
4.8.2
Krok přesouvání
K přesunutí jsou určeny remote verze položek ze struktury objectsToDelete a objectsToExport. Položky v objectsToExport neobsahující remote verzi nejsou určeny k přesouvání.
Protože IMAP protokol neobsahuje příkaz pro přesunutí zprávy (MOVE), ale pouze
COPY pro zkopírování, přesunutí je realizováno jako kopírování zprávy do cílové složky a
její následné odstranění ze složky původní. Pro odstraňování zpráv je v protokolu vyčleněn
příkaz EXPUNGE, který jednorázově odstraní všechny zprávy ve složce označené příznakem
\Deleted, přičemž příznaky se zprávám přidávají pomocí příkazu STORE.
Přesouvání je tedy realizováno operacemi v tomto sledu:
1. zkopírování přesouvaných zpráv do podsložky „Deleted“,
2. nastavení příznaku \Deleted k originálům zpráv,
3. trvalé odstranění zpráv s tímto příznakem.
První dvě operace jsou realizovány postupně po jedné zprávě, voláním příkazů UID
COPY resp. UID STORE. UID COPY vyžaduje jako parametr sekvenci zpráv a název
složky, do které se mají zprávy zkopírovat. UID STORE sekvenci zpráv a příznak, který má
být zprávě přidán. Po každém volání UID STORE se pro dané číslo RevId v databázi změní
hodnota atributu entryPresent na false. Po nastavení příznaku ∖Deleted poslední zprávě
je zavolán příkaz EXPUNGE na vyčištění složky. Tak jsou zkopírované zprávy odstraněny.
Tím je dosaženo stavu, kdy si obsah složky vzdáleného úložiště s lokální složkou odpovídají,
synchronizace je tím ukončena.
Příklad
Příkazy volané ve fázi export pro náš příklad ukazuje následující výpis komunikace klientserver. Pro přehlednost jsou volání klienta zvýrazněna. Z tabulek struktur objectsToExport a
objectsToDelete je vidět, že zprávy k přesunutí jsou celkem 3 (RevId 915 z objectsToDelete,
910 a 923 z objectsToExport). Příkazy UID COPY a UID STORE jsou tudíž volány každý
třikrát. V odpovědi na příkaz UID COPY jsou vidět parametry zprávy nově přidané do
podsložky, v odpovědi na UID STORE aktuální stav příznaků u zprávy a počet zbývajících
zpráv ve složce (pro ExtBrain Sync není důležité).
4.9. PARALELNÍ PŘÍSTUP
1
2
39
A004 UID COPY 915:915 extbrainContacts/Deleted
A004 OK [COPYUID 660858847 915 43] (Success)
3
4
5
6
7
8
9
10
11
12
13
14
A007 UID STORE 915:915 +FLAGS (\Deleted)
* 6 FETCH (FLAGS (\Seen \Deleted) UID 915)
* 6 EXPUNGE
* 5 EXIST
A007 OK Success
15
16
17
18
...
A008 OK Success
19
20
21
22
...
A009 OK Success
23
24
25
A010 EXPUNGE
A010 OK Success
4.9
Paralelní přístup
Protokol je navržen tak, že podporuje současný přístup pouze jedné klientské aplikace.
Během synchronizačního procesu nastávají chvíle, kdy jsou data ve vzdáleném úložišti v nekonzistentním stavu (typicky mezi uložením nové verze položky a odstraněním staré). Pokud
by v tuto chvíli jiný klient načítal ze vzdáleného úložiště, budou jím získané údaje neúplné.
Pro zamezení současného přístupu více klientů najednou jsou v protokolu synchronizační
zámky.
4.9.1
Zamykání vzdáleného úložiště
Klient se před zahájením importní fáze synchronizace pokusí zamknout nad vzdáleným
úložištěm zámek. Jako zámky slouží IMAP zprávy ukládané do podsložky „lock“. Při pokusu
o zamčení úložiště klient do této složky vloží zprávu, které je přiděleno serverem jednoznačné
UID. Žádá-li o zamčení více klientů najednou, jejich zprávy se do složky zařadí postupně
jako do fronty. Pokračovat v synchronizaci však bude pouze jeden z nich; ten, jenož zpráva
reprezentující zámek byla do složky vložena nejdříve.
Klientská aplikace tedy ověří, zda je jím odeslaná zpráva na prvním místě. To je implementováno jako získání nejstarší zprávy ve složce. Shoduje-li se UID této zprávy a zprávy,
40
kterou klientská aplikace na server odeslala, úložiště je úspěšně uzamčeno pro danou aplikaci
a ta může pokračovat v synchronizaci. Pokud se tato UID neshodují, složka byla uzamčena
jiným klientem a aktuální klient svůj zámek ze složky odstraní. Stejně tak i klient, který
pro svoji potřebu úložiště úspěšně zamkl, po dokončení synchronizace odemkne úložiště
odstraněním svého zámku.
Stavový diagram zamykání vzdáleného úložiště je na obrázku 4.6.
Obrázek 4.6: Stavový diagram zamykání vzdáleného úložiště
Kapitola 5
Realizace
5.1
Obecný synchronizační modul
Obecný synchronizační modul informací je implementován několika třídami, prostřední vrstvu
tvoří třída CommonSync. Diagram tříd synchronizačního modulu je na obrázku 5.1. Třídy
ItemSync a RemoteStorageHandler jsou abstraktní. V class diagramu ukazují, jaké metody musí mít jejich konkrétní implementace, aby s nimi dokázala CommonSync komunikovat. Konkrétními implementacemi jsou ContactSync (rozšíření modulu o synchronizaci kontaktů), ImapSync a ImapSyncController (realizace spodní vrstvy architektury pro podporu
IMAP úložiště). Pomocí atributů this.itemsAPI a this.communicationAPI jsou v CommonSync uchovány reference na instance těchto konkrétních tříd. Struktura položek a synchronizační tabulky byla uvedena již v definici protokolu, není tedy třeba ji zde znovu uvádět.
5.1.1
Průběh volání v jednotlivých fázích synchronizace
Sekvenční diagram celého procesu synchronizace je na obrázku B.2 v příloze této práce. V
následujících odstavcích je rozebrán flow programu po jednotlivých fázích.
Fáze import
První fáze synchronizace je celá realizována pomocí vrstvy remote storage. V případě vzdáleného úložiště IMAP konkrétně objektem třídy ImapSync a ImapSyncController. Objekt
commonSync volá this.communicationAPI.import(this) pro zahájení importu. Metodě je v
parametru předáno scope, aby po sérii asynchronních voláních v IMAP knihovně dokázal
vrátit běh synchronizace k druhé fázi – jádru synchronizace. Po načtení položek ze vzdáleného úložiště tedy obsluha IMAP knihovny (ImapSyncController) vrací běh programu
pomocí scope.callMakeSyncTable(incommingItems) zpět do třídy CommonSync.
Sekvenční diagram volání při importní fázi je na obrázku 5.2.
41
42
KAPITOLA 5. REALIZACE
Obrázek 5.1: Class diagram synchronizačního modulu
Fáze synchronizační jádro
První krok synchronizačního jádra – vytvoření synchronizační tabulky – obstarává horní
vrstva synchronizace, volá se proto this.itemsAPI.makeSyncTable(incommingItems). Třída
implementující toto items API musí zajistit vytvoření synchronizační tabulky dle definice v
kapitole ExtBrain Sync Protokol. Volání v horní vrstvě nejsou asynchronní, proto může být
synchronizační tabulka předána zpět do CommonSync přes návratovou hodnotu. Průchod
synchronizační tabulkou je implementován v metodě handleSyncTable třídy CommonSync.
Zde jsou uvnitř cyklu implementovány podmínky pro nastalé situace přesně podle definice
v protokolu. Obsluhu situací podporují metody initialItemHandling, createItem, deleteItem,
acceptChange a handleCollision, (tyto nejsou pro zjednodušení uvedeny v class diagramu).
Uvnitř těchto metod totiž neprobíhá fyzická manipulace s položkami (třída Common sync
toto ani neumí), pouze se zde volají příslušné metody z items API, probíhá update verzí v
databázi, případně se položky vkládají do objectsToExport a objectsToDelete.
Fáze export
Exportní fáze je opět celá v režii vrstvy remote storage. Třídě implementující tuto vrstvu
jsou předány objekty objectsToExport, objectsToDelete a scope, aby po uložení položek na
server mohla ohlásit konec synchronizačního procesu do třídy CommonSync pomocí metody
terminate s parametrem true – synchronizace se zdařila, nebo false – během exportní fáze se
vyskytla chyba. Volání při fázi export jsou podrobně rozkreslena v obrázku 5.3. Všimněme si,
že v diagramu není vůbec zachycen objekt třídy ContactSync, který se na této fázi nepodílí.
5.2. DATABÁZOVÉ ÚLOŽIŠTĚ
43
Obrázek 5.2: Sekvenční diagram fáze import
Obrázek 5.3: Sekvenční diagram fáze export
5.2
Databázové úložiště
Pro ukládání databázových verzí položek slouží databázový stroj SQLite, který je součástí
jádra Mozilla Thunderbird [13]. Informace o účtech jsou dekomponovány do dvou tabulek.
Tabulka loginInfo obsahuje obecné informace o vzdáleném úložišti, tabulka account zahrnuje
informace o konkrétních účtech namapovaných na složku ve vzdáleném úložišti a na lokální
úložiště. Ke konkrétnímu účtu se pak váží řádky v tabulce sync, která obsahuje informace o
verzích položek. Primárním klíčem této tabulky je dvojice <revId : accountUID>. Pro jeden
účet totiž nesmí existovat více položek se stejným číslem revize. Relační schéma databáze
je na obrázku 5.4.
Heslo k účtu na serveru není uloženo v databázi, v Mozilla Application Frameworku existuje pro hesla speciální podpora skrze password manager. Odtud se heslo získává při každé
synchronizaci. Lokální adresář je v případě synchronizace kontaktů uložen jako URI objektu
nsIAbDirectory – kontejneru pro objekty kontaktů. Při změne názvu adresáře zůstává URI
stejná.
44
Obrázek 5.4: Relační databázový model
Nejčastějším dotazem nad databází je při synchronizaci získání poslední verze položky
ve tvaru:
SELECT * FROM sync WHERE itemId = ’abc’ AND accountUID = ’def’
ORDER BY revId DESC LIMIT 1
Proto je nad tabulkou sync vytvořen index přes sloupce <revId, itemId, account>. Chování
databázového stroje SQLite při zpracovávání tohoto dotazu bylo ověřeno nad stovkami řádků
a index uchovávající revId v sestupném řazení vyšel z možných variant jako nejvýhodnější.
5.3
Obsluha IMAP úložiště
Obecný synchronizační modul je navržen tak, aby nezávisel na vrstvě obsluhující vzdálené
úložiště. V této práci je vzdáleným úložištěm IMAP server, takže implementace této vrstvy
je spojovníkem mezi common sync vrstvou a IMAP knihovnou. Třída ImapSync přebírá od
CommonSync parametry (účet, položky k zápisu) a předává je do třídy ImapSyncController,
která zajišťuje obsluhu IMAP klienta uvnitř knihovny. ImapSync obsahuje metody lock,
import a export, všechny slouží pouze k vyvolání příslušných částí obsluhy IMAP klienta.
ImapSyncController obsahuje řadu atributů (vnořených objektů), které vyvolávají akce v
klientovi. Pomocí callbacků, které jsou součástí atributů se běh aplikace vrátí zpět do místa,
odkud se příkaz klientovi posílal.
5.3.1
Posloupnost IMAP příkazů
Požadovaného sledu příkazů při importní a exportní fázi je dosaženo přes sekvenci callbacků.
Pro obecné použití je vytvořena initialSequence, která obsahuje navázání spojení se serverem
a příkaz LOGIN, a disconnectSequence obsahující příkazy EXAMINE a LOGOUT. Díky příkazu EXAMINE ještě před odpojením je možné modifikovat záznam o účtu v databázi tak,
5.3. OBSLUHA IMAP ÚLOŽIŠTĚ
45
aby zde byly aktuální údaje o počtu existujících položek ve vzdáleném úložišti (EXISTING)
a NEXTUID. Dále jsou pak vytvořeny importSequence a exportSequence. Sled příkazů v
jednotlivých sekvencích je následující.
initialSequence
importSequence
exportSequence
disconnectSequence
connect, LOGIN
SELECT, UID FETCH (hlavičky zpráv), UID FETCH (celé zprávy)
APPEND, UID COPY, UID STORE, EXPUNGE
EXAMINE, LOGOUT
Sekvenční diagramy znázorňující postup volání příkazů do IMAP knihovny v initial,
import a export sekvenci jsou na obrázcích B.3, B.4 a B.5 v příloze této práce. Všechna
volání jsou asynchronní, proto v diagramech nezachycuji životnost objektu. Metodám uvnitř
IMAP knihovny je znázorněno předání prostředí přes scope.
5.3.2
Struktura obsluhy volání IMAP příkazu
Struktura objektu pro volání konkrétního příkazu vypadá následovně. V metodě command
se vždy zavolá příkaz v IMAP klientu s patřičnými parametry (zde název složky, která
má být vybrána), metody okay a fail jsou callbacky, které jsou zavolány z klienta po příchodu a vyhodnocení odpovědi od serveru. Všimněme si přiřazení scope.current = this;
v řádku 3. V případě, že se vybrání složky podaří, běh aplikace se vrátí do callbacku okay
a rozhoduje se, kam se bude běh programu odebírat dál (popsáno v dalším odstavci), v
případě neúspěchu se vrátí do callbacku fail. ImapSyncController se tak odpojí od serveru
a zavolá ukončení synchronizace (řádky 19 a 20).
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
select : {
command : function(scope) {
scope.current = this;
scope.client.select(scope.account.folderStr);
},
okay : function(scope, response) {
if (response.nextUID == scope.account.nextUID
&& response.existingItems == scope.account.existingItems ) {
scope.runDisconnect();
var incommingItems = {changed: "false", items: new Object()};
scope.syncScope.callMakeSyncTable(scope.syncScope, incommingItems);
}
else {
scope.importSequence.fetchUuids.command(scope);
}
},
fail : function(scope, response) {
printOutput(’Select failed’);
scope.runDisconnect();
scope.syncScope.termination(false);
}
}
46
Při fázi import je volána nejprve úvodní sekvence příkazů (initialSequence), na níž naváže
importSequence. Z importSequence lze po každém příkazu vystoupit (a ukončit fázi import),
pakliže není nutné načítat další podrobnosti o zprávách. Toto je implementováno dle obrázku
4.2. Ukončení importSequence před vykonáním celého sledu příkazů je realizováno pomocí
podmínek v okay callbacích jednotlivých příkazů.
Opuštění fáze import
Předčasné ukončení sekvence příkazů je ilustrováno také v předchozí ukázce objektu select.
V okay callbacku na řádku 7 je podmínka na rovnost parametrů UIDNEXT a EXISTING
z odpovědi serveru (aktuální) a z databáze (předchozí synchronizace). V případě, že se tyto
parametry rovnají, ukončíme běh importSequence. IMAPSyncController má přes atribut
syncScope k dispozici metody z CommonSync, takže vystoupení ze sledu příkazů se děje
zavoláním scope.syncScope.callMakeSyncTable (řádek 11). V parametrech volání je uvedeno
scope.syncScope. To proto, aby instance CommonSync měla opět k dispozici všechny svoje
atributy. Druhým parametrem je nově vytvořený objekt incommingItems, který obsahuje
atribut changed nastavený na false. Pomocí incommingItems se do obecného jádra vrací
seznam načtených položek. Atribut changed slouží k rozlišení situace, kdy ve vzdáleném
úložišti nebyly vykonány změny (incommingItems.items je prázdný, protože položky nebyly
získávány) a kdy byly vykonány změny a incommingItems.items je prázdný proto, že byly
všechny položky smazány. Obsahuje-li přijímaná položka přílohu, je tato uložena do profilového adresáře do podsložky „ExtBrainSync“ a odkaz na tento soubor je předán společně
s obsahem položky dále do synchronizačního jádra.
Export fáze
Při fázi export sled sekvencí příkazů závisí na obsahu polí objectsToExport a objectsToDelete. Pro zjednodušení obsluh volání příkazů se položky, jejichž verze mají být zapsány, a
pro které zároveň mají být předchozí verze přesunuty, kopírují z objectsToExport do objectsToDelete ve třídě IMAPSync v metodě export. Jsou-li obě pole prázdná, exportní fáze
je ukončena bez volání obsluhy IMAP klienta. Je-li objectsToExport neprázdné pole, je vyvolána nejprve initialSequence, poté exportSequence. Mezi sekvencemi se přechází pomocí
konstruktů v callbacích podobných těm, které jsou popsány v předchozím odstavci. Sled
příkazů je přesnou implementací stavového diagramu v obrázku 4.5. Po úspěšném vykonání
všech potřebných IMAP příkazů se běh programu vrací zpět do instance třídy CommonSync
zavoláním scope.syncScope.termination(true).
5.3.3
Zamykání vzdáleného úložiště
Zamykání vzdáleného úložiště před provedením synchronizace je také v režii tříd IMAPSync
a IMAPSyncController. Volání požadované sekvence příkazů (APPEND zámku a následný
FETCH) je provedeno pomocí sekvencí s callbacky stejně jako je tomu ve fázích import a
export.
Pokud se během synchronizace vyskytne závažná chyba, například se ztratí připojení k
serveru, zámek není možné z úložiště odstranit a to tak zůstává trvale zamčené. Proto pokud
5.4. SYNCHRONIZAČNÍ MODUL KONTAKTŮ
47
při další synchronizaci klient zjistí, že je zamčeno, nabídne uživateli možnost výběru. Buď
může tento fakt přijmout a přerušit synchronizaci, nebo, pokud například víme, že zámek ve
složce zůstal díky chybě, zamčení obejít a pokračovat v synchronizaci dále. V obou případech
aplikace před ukončením ze složky odstraní pouze svůj zámek. Zámek obsahuje informace o
datu, času a v předmětu název počítače a profilu v Thunderbirdu, ze kterého byl odeslán.
„Zaseknutý“ zámek může uživatel odstranit v e-mailovém klientu jednoduše odstraněním
zprávy se zámkem.
5.3.4
IMAP knihovna
V IMAP knihovně implementované Petrem Machem bylo provedeno několik změn. Do klienta
byly přidány příkazy EXAMINE, UID FETCH, UID COPY, UID STORE a EXPUNGE.
Třída odesílající data do socketu MozExtbrainToolkit byla upravena tak, aby podporovala
i znaky mimo ASCII. Dále byla rozšířena třída IMAPParser tak, aby dokázala převádět a
parsovat příchozí data zakódovaná v quoted printable formátu.
5.4
5.4.1
Synchronizační modul kontaktů
Implementace
Rozšiřující modul k synchronizaci kontaktů je implementován třídou ContactSynchronization, která tvoří items layer. Tato třída obsahuje metody pro manipulaci s položkami
makeSyncTable, initialItemsHandling, createItem, deleteItem, acceptChange, handleCollision a další 2 metody na serializaci a deserializaci položek – serialize, deserialize. Třída
je implementací rozhraní ItemSync. Stejně je to zachyceno i v class diagramu na obrázku
5.1.
Za zvláštní zmínku stojí metoda initialItemsHandling, jejíž význam není možná zcela
zřejmý. Metoda je volána v situaci, kdy byla vytvořena nová lokální položka. Během serializace je položce přiřazeno UUID, tento identifikátor je ale nutné uložit přímo do objektu
položky, abychom ji rozlišili při další synchronizaci. Toto zpětné uložení už ale serializace
nezajišťuje a proto musíme před exportem nových položek serializovaná data včetně nově
vytvořeného identifikátoru deserializovat zpět do objektu položky.
5.4.2
Definice formátu obsahu přenášených zpráv
Těla přenášených zpráv při synchronizaci kontaktů mají podobu textové reprezentace JSON
objektů [14]. Pro bezchybnou synchronizaci je nutné definovat přesný tvar objektů v tomto
kontejneru.
JSON obsahuje objekty ve tvaru <atribut : element>, kde element může mít tři různé
typy: string, pole objektů, objekt. Je-li element typu objekt, skládá se ze seznamu subatributů ve tvaru <subatribut : string>. Kontaktní synchronizační modul zná atributy
uvedené v tabulce 5.1. Kromě uvedených subatributů obsahuje každý element typu objekt v
JSONu ještě pomocné subatributy sync a primary. Primary je použito v OS Android pro vyznačení primární položky daného atributu, je typu boolean. Existuje-li například pro jeden
48
kontakt více telefonních čísel, můžeme zvolit, které bude upřednostňováno. Subatribut sync
má formát UUID a slouží jako identifikátor elementu. Elementy mohou být do JSONu skládány v různém pořadí a právě sync slouží k tomu, abychom při synchronizaci mohli srovnat
odpovídající si elementy k sobě a zjistit jejich změny. Při řešení kolizí je pomocí subatributu
sync možné identifikovat elementy a odlišit tak situaci, kdy byl jeden element změněn od
situace, kdy byl vytvořen nový. (V prvním případě má řešením kolize být změna elementu,
ve druhé zřetězení těchto elementů.) Ukázka, jak vypadá kontakt se všemi podporovanými
atributy v JSON podobě je v tabulce B.1.
V tabulce 5.1 jsou uvedené i podporované řetězce v subatributech type. Tato množina
je omezená, jedná se o řetězce nativně podporované v OS Android. Je-li jako typ elementu
zvoleno „custom“ znamená to, že v elementu je obsažen subatribut „label“, který obsahuje
uživatelem zadaný vlastní typ elementu. Takto lze vytvořit například událost typu svátek:
event": [{"type":"custom", "label": "svátek", "value": "0000-11-04", "sync":
"ccb515f3-2d80-498c-9ae6-b256e9ee93e8", "primary": "false"}
5.4.3
Serializace a deserializace kontaktů
Přeměna položek z objektů nsIAbCard do podoby JSON se provádí v metodě exportContactProperties procházením přes všechny defaultní a přidané atributy kontaktů. Kromě přidaných atributů přímo přístupných uživateli skrze grafické uživatelské rozhraní je ale i několik
atributů „skrytých“. Synchronizace totiž musí pasivně podporovat i atributy, které Thunderbird ani s nově přidanými atributy nezná. Představit si to lze například na údajích o
společnosti, kde osoba v kontaktu pracuje. Tyto údaje jsou v Thunderbirdu a v OS Android
shrnuty jen na tyto tři: název společnosti, oddělení, funkce. Některá jiná platforma, která
bude v budoucnu do synchronizace zapojena, ale může tyto informace rozšiřovat například
o číslo kanceláře apod. O takovéto informace nesmíme během synchronizace přijít, jak by se
to stávalo pouhým uložením „známých“ atributů do objektu nsIAbCard a jejich pozdějším
vytažení zpět do JSONu. I tyto pro synchronizační modul neznámé atributy musejí být uloženy společně s ostatními tak, abychom je při dalším exportu z objektu, dokázali složit do
původní podoby. Uživatel k těmto atributům logicky má přístup jen v platformě, která tyto
typy „aktivně“ podporuje, tzv. zobrazuje jejich hodnoty v GUI a umožňuje jejich editaci.
Při každém importu (zápisu obsahu JSONu do objektu nsIAbCard) se do speciálních
properties uloží v textové podobě i všechny elementy z JSONu. Při dalším exportu (serializaci) se tyto původní elementy vytáhnou a provede se sloučení původních elementů s nově
exportovanými atributy. Tím je zajištěno, že v nově vyexportovaných elementech nebudou
chybět i subatributy, které nejsou podporovány. Toto slučování probíhá s využitím sync
subatributů v každém elementu.
5.4.4
Chyba v jádru Thunderbirdu
Během vývoje byla objevena a reportována chyba v jádru aplikace Thunderbird. Je-li ke
kontaktu přiřazena fotografie, vytvoří se její kopie v profilovém adresáři aplikace. Po odstranění kontaktu ale soubor s fotografií v adresáři zůstává a zbytečně tak zabírá místo na
5.4. SYNCHRONIZAČNÍ MODUL KONTAKTŮ
atribut
uuid
displayName
name
typ
string
string
object
phone
array
email
array
urls
array
event
array
organization
array
im
array
subatribut
givenName
familyName
displayName
type
value
type
value
type
value
type
value
company
department
title
type
type
value
protocol
sipAddress
array
addresses
array
nickname
array
type
value
type
streetAddress
neighborhood
city
region
postalCode
country
type
array
array
value
photoName
note
photo
note
typ možnosti
home, mobile, work, fax_work,
fax_home, pager, other, callback,
car, company_main, isdn, main,
other_fax, radio, telex, tty_ttd,
work mobile, work_pager, assistant,
mms, custom
home, work, mobile, other, custom
home, work, mobile, other, custom
birthday, anniversary, custom
work, other, custom
home, work, other, custom
aim, msn, yahoo, skype, qq, googleTalk, icq, jabber, netmeeting, custom
default,
other_name,
maiden_name, short_name, initials,
custom
Tabulka 5.1: JSON atributy
49
50
disku. Fotografie, které jsou přenášeny v rámci synchronizace jsou uloženy také v profilovém adresáři aplikace ve složce „ExtBrainSync“. Aby nedocházelo k plýtvání místem, je v
možnostech zásuvného modulu přidáno tlačítko na vyčištění této složky, které odstraní fotografie navázané na již neexistující kontakty. Při změně fotografie u kontaktu je případná
stará verze z toho adresáře odstraněna ihned.
5.4.5
Řešení kolizních situací
Kolizní situace jsou v případě kontaktů řešeny zobrazením okna shrnujícího všechny verze
kontaktu. V tomto okně uživatel vybere podobu atributů tak, jak je chce zahrnout do
výsledné položky této kolize. Při zobrazování atributů je aplikován algoritmus trojcestného
slučování (viz. jeho popis v podkapitole Princip synchronizace). Algoritmus prochází přes
hodnoty v atributech položky, zvýrazňuje shodné verze a na základě těchto shod předvybírá
hodnoty do výsledné verze. Samotný výběr hodnot je ale na uživateli. Zeleným zvýrazněním
je ukázáno, že kolize v atributu byla vyřešena, červeně pak situace, kdy jsou všechny tři
verze rozdílné a verzi položky musí zvolit uživatel.
5.5
5.5.1
Grafické uživatelské rozhraní
Rozšíření atributů kontaktu
Okno pro editaci kontaktů se skládá z několika karet obsahujících vždy ovládací prvky k
editaci podobných typů položek. V tomto okně je nově karta s názvem „Instant messaging“
obsahující informace o IM a SIP účtech k danému kontaktu. V případě přidání typů k
atributům je před textbox pro zadání hodnoty atributu vytvořen menulist, což je vstupní
prvek typu „roleta“, ve kterém uživatel vybere z předem definovaných řetězců typů.
Zde je místo pro možný další rozvoj aplikace. U typu atributu „custom“ je skutečný
typ jako uživatelem zadaný vlastní řetězec uložen v atributu „label“. Tento atribut není
v této verzi synchronizačního modulu uživateli přístupný. Pro jeho zpřístupnění je nutný
větší zásah do GUI okna pro editaci kontaktů (je možné přeuspořádání ovládacích prvků,
zobrazení vyskakovacího okna pro zadání konkrétné hodnoty atd.).
Ukládání položek po uzavření editačního okna se i v jádru Thunderbirdu děje průchodem přes předem definované pole známých atributů a uložení jejich hodnot do objektu
nsIAbCard. Uložení přidaných atributů je provedeno stejně. Názvy přidaných atributů jsou
uloženy v souboru attributes.js. Při tvorbě grafického rozhraní byla použita příručka jazyka
XUL z [15]. Okno pro editaci kontaktů je ukázáno na obrázku 5.5.
5.5.2
Wizard na tvorbu účtů
Před samotnou synchronizací je nutné vytvořit účet se všemi potřebnými údaji o serveru,
lokální a vzdálené složce. Protože je důležité mít jistotu, že bylo zadáno správné uživatelské
jméno a heslo k serveru, zda tento server existuje atd., byl tento účel vytvořen průvodce
vytvořením účtu. Průvodce je spuštěn pravým kliknutím na složku kontaktů v adresáři a
5.5. GRAFICKÉ UŽIVATELSKÉ ROZHRANÍ
51
Obrázek 5.5: Okno pro editaci kontaktů s rozšířenými atributy
zvolením „Add ExtBrain Sync account“. Průvodci pak uživatel zadává přihlašovací údaje k
serveru, tyto informace jsou uloženy v databázi v tabulce loginInfo, a tak je při vytváření
více účtů namapovaných na složky na jednom serveru nemusí zadávat opakovaně. Průvodce
přidáním účtu se pak pokusí k serveru přihlásit a získat odtud seznam všech složek. Z nich
uživatel vybírá, nebo může zadat název nové složku, která je po potvrzení vytvořena (včetně
podsložky „Deleted“). Tím je ošetřeno, že složka v nově zadaném účtu skutečně existuje a
účet má platná přihlašovací data.
5.5.3
Obsluha synchronizace
Kontextové menu na složku kontaktů v adresáři má dvě různé podoby. Je-li na složku zaregistrován synchronizační účet, zobrazují se volby „Start sync“ a „Remove ExtBrain Sync
account“, není-li složka v seznamu účtů, zobrazuje se „Add ExtBrain Sync account“. Pro
spolehlivou synchronizaci je nutné zajistit, aby složka, na níž je namapován synchronizační
účet existovala. Již bylo zmíněno, že v databázi je lokální složka uložena jako URI nsIAbDirectory, změna názvu složky tedy synchronizaci nerozbije. Při odstranění složky se odstraní
účet i všechna historická data o synchronizacích tohoto účtu.
Synchronizace složky kontaktů se spouští z kontextového menu příkazem „Start sync“
(viz obrázek C.3). Po jeho vyvolání se zobrazí okno syncLog.xul (viz obrázek 5.6) obsahující
informace o složce a serveru, kam se lokální adresář sychronizuje, je zde i místo pro výpis
aktuálně prováděných operací včetně případných chyb. Při vyvolání synchronizace se pro
lepší user experience (např. při dlouhých prodlevách při načítání zpráv) v tomto okně deaktivuje tlačítko „OK“, které je aktivováno po skončení synchronizace, nebo při závažné chybě
vedoucí k nemožnosti synchronizaci dokončit.
52
Obrázek 5.6: Okno informující o průběhu synchronizace
Kapitola 6
Testování
V průběhu vývoje bylo autorem této práce prováděno funkční testování. Na počátku vývoje
byla funkčnost serializace a deserializace rozšířených kontaktních atributů ověřována přes
modul pro synchronizaci kontaktů přes složku na lokálním disku. Tento modul byl posléze
pro komplexnost synchronizačních procesů z aplikace odstraněn. Funkčnost obecného synchronizačního modulu (knihovny) byla ověřena přes modul k synchronizaci kontaktů. Ten
lze testovat jednak posíláním dat z několika profilů aplikace Mozilla Thunderbird a proti
ExtBrain synchronizační aplikaci pro operační systém Android, kterou vyvinul v rámci diplomové práce Ing. Luboš Hilgert [16].
Po dokončení vývoje byl synchronizační modul testován vedoucím práce a okruhem testerů sestávajího se z bývalých vývojářů projektu ExtBrain. Testování synchronizačního modulu bylo prováděno v aplikaci Mozilla Thunderbird ve verzích 10, 11 a 12. Přestože zásuvný
modul závisí pouze na hostitelské aplikaci a měl by se v různých operačních systémech chovat stejně, byl otestován v operačních systémech Microsoft Windows XP, Vista a 7 a v Linux
Ubuntu 11.
Synchronizace byla ověřena pro následující IMAP servery:
∙ imap.feld.cvut.cz,
∙ imap.gmail.com,
∙ imap.aol.com,
∙ imap.mail.yahoo.com.
Některé servery bohužel nejsou implementované podle RFC 3501 a tak například nepodporují vícenásobné vnořování složek (imap.centrum.cz, imap.seznam.cz) nebo před název
uživatelem vytvořené složky přidávají vlastní řetězec (imap.seznam.cz). Podpora pro tyto
servery je tedy omezená. Funkčnost závisí na tom, zdali se podaří vytvořit synchronizační
složku a její podsložku s názvem „Deleted“.
Charakter vytvořené práce se během vývoje změnil ze samostatné aplikace spíše ke knihovní aplikaci, která je v současné době portována do většího projektu ExtBrain Communicator kolegou Bc. Davidem Jirovcem. Po dohodě s vedoucím práce tedy nebyly prováděny
53
54
KAPITOLA 6. TESTOVÁNÍ
speciální testy zaměřující se na uživatelské rozhraní synchronizačního modulu. Funkčnost
modulu je nyní ověřována již během testů při vývoji výše zmiňované aplikace. Uživatelské
rozhraní, které je v aplikaci obsaženo slouží k vytváření účtů a k demonstraci funkčnosti
synchronizace.
Kapitola 7
Závěr
Výsledkem této práce je synchronizační modul v aplikaci Mozilla Thunderbird, který je
možné využít pro synchronizaci jakýchkoli textových informací včetně příloh v binárním
tvaru. Synchronizační modul je obecný a je nezávislý na vzdáleném úložišti, konkrétně je
implementována podpora pro vzdálené úložiště v podobě IMAP serveru. Funkčnost tohoto
modulu je ukázána na vytvořeném zásuvném modulu pro synchronizaci kontaktů ve stejné
hostitelské aplikaci. V práci byl popsán ExtBrain Sync protokol, podle kterého se celá synchronizace řídí. Synchronizační aplikaci podle stejného protokolu implementoval pro OS
Android ve své diplomové práci Ing. Luboš Hilgert. Díky těmto dvěma modulům je tedy
možné synchronizovat kontaktní informace z Thunderbirdu s telefonem. Na práci navazuje
projekt Bc. Davida Jirovce s názvem ExtBrain Communicator, která modul přebírá a implementuje synchronizaci kalendářových dat a poznámek.
Práce naplnila všechny požadavky, po dohodě s vedoucím došlo k jediné úpravě v zadání
a to k ustoupení od rozsáhlejších testů uživatelského rozhraní z důvodu integrace modulu
do většího projektu, které bude mít svoje vlastní uživatelské rozhraní.
7.1
Možná další rozšíření
Na projekt je možné kdykoli navázat implementací modulů pro synchronizaci dalších typů
položek. Dále je možné zabývat se vylepšeními speciálně v těchto ohledech:
Grafické uživatelské rozhraní pro editaci kontaktů V okně pro editaci kontaktů je
staticky zobrazeno několik polí pro zadávání hodnot konkrétních atributů. Ovládací prvky v
tomto okně by mohly být přeuspořádány tak, aby se zobrazovaly vždy jen zadané hodnoty.
Další řádek pro přidávání hodnot by se zobrazil kliknutím na tlačítko „+“. Synchronizační
modul je na toto připraven, počet hodnot pro jeden atribut není omezen.
Dále je zde možnost vytvořit podporu zadávání vlastních štítků pro atributy, jako je
tomu v OS Android. (Např. možnost přidat typ adresy „přechodné bydliště“.)
55
56
KAPITOLA 7. ZÁVĚR
Automatická synchronizace pomocí IMAP push Pro IMAP protokol existuje rozšíření s názvem push-email, který zajišťuje odeslání zpráv z IMAP serveru na klienta ihned po
přijetí zprávy serverem, bez nutnosti opakovaného dotazování klientem na stav serveru. Tuto
technologii by bylo možné přidat do synchronizačního modulu tak, aby se informace ihned
po změně a uložení na server replikovaly i na další připojené klienty. S touto technologií
pracuje synchronizační standard SyncML.
Literatura
[1] NOVOTNÝ, Tomáš. ExtBrain – to simplify everyday tasks [online]. [cit. 18. 11. 2011].
Dostupné z: http://extbrain.felk.cvut.cz
[2] Zimbra Email and Collaboration Server [online]. 2012 [cit. 5. 11. 2011].
Dostupné z: http://www.zimbra.com/products/email-server.html
[3] KHANNA, Sanjeev, Keshav KUNAL, a Benjamin PIERCE: A Formal Investigation of
Diff3. [online]. [2007] [cit. 14. 1. 2012].
Dostupné z: http://www.cis.upenn.edu/~bcpierce/papers/diff3-short.pdf
[4] CRISPIN, M. RFC 3501 - INTERNET MESSAGE ACCESS PROTOCOL - VERSION
4rev1 [online]. 2003 [cit. 10. 12. 2011].
Dostupné z: http://www.faqs.org/rfcs/rfc3501.html
[5] CROCKER, David H. RFC 822 - STANDARD FOR THE FORMAT OF ARPA INTERNET TEXT MESSAGES [online]. August 13, 1982 [cit. 10. 12. 2011].
Dostupné z: http://www.ietf.org/rfc/rfc0822.txt
c 2011
[6] PETERKA, Jiří. RFC 822. Jiří Peterka: archiv článků a přednášek [online]. ○
[cit. 14. 1. 2012].
Dostupné z: http://www.earchiv.cz/a94/a435c110.php3
[7] BOSSWELL, David, Brian KING, Ian OESCHGER aj. Creating Applications with Mozilla. First edition. Sebastopol, CA, USA: O’Reilly Media, 2002.
[8] NYMAN, Robert. How to develop a Firefox extension [online]. 2009 [cit. 7. 10. 2011].
Dostupné
z:
http://blog.mozilla.org/addons/2009/01/28/
how-to-develop-a-firefox-extension/
c 2005-2012. [cit. 5. 3. 2012].
[9] Mozilla. Mozilla Developer Network [online]. ○
Dostupné z: https://developer.mozilla.org/en/
[10] ContactsContract.CommonDataKinds. Android Developers [online]. 2012 [cit.
14. 1. 2012].
Dostupné
z:
http://developer.android.com/reference/android/provider/
ContactsContract.CommonDataKinds.html
[11] SMARR, Joseph. Portable Contacts 1.0 Draft C [online]. August 5, 2008 [cit.
12. 2. 2012].
Dostupné z: http://portablecontacts.net/draft-spec.html
57
58
LITERATURA
[12] Introducing JSON. [online] [cit. 12. 2. 2012].
Dostupné z: http://www.json.org
[13] SQLite - Documentation [online]. [cit. 12. 2. 2012].
Dostupné z: http://www.sqlite.org/docs.html
[14] CROCKFORD, Douglas. The application/json Media Type for JavaScript Object Notation (JSON) [online]. July 2006 [cit. 12. 2. 2012].
Dostupné z: http://www.ietf.org/rfc/rfc4627
[15] Mozilla Developer Network. XUL reference [online]. 26 April 2010 [cit. 5. 3. 2012].
Dostupné z: https://developer.mozilla.org/en/XUL_Reference
[16] HILGERT, Luboš. Modul pro správu informací pro Android. Praha, 2012. Diplomová
práce. České vysoké učení technické v Praze.
Příloha A
Seznam použitých zkratek
API Application Programming Interface
DOM Document Object Model
IM Instant Messaging
IMAP Internet Message Access Protocol
JSON JavaScript Object Notation
OS Operating System
SIP Session Initiation Protocol
TH Thunderbird
URI Uniform Resource Identifier
UUID Universally Unique IDentifier
XUL XML User Interface Language
59
60
PŘÍLOHA A. SEZNAM POUŽITÝCH ZKRATEK
Příloha B
Obrázky a diagramy
Obrázek B.1: Návrh okna pro editaci kontaktů
61
62
PŘÍLOHA B. OBRÁZKY A DIAGRAMY
Obrázek B.2: Sekvenční diagram všech fází synchronizace
63
Obrázek B.3: Volání IMAP příkazů v initialSequence
64
Obrázek B.4: Volání IMAP příkazů v importSequence
65
Obrázek B.5: Volání IMAP příkazů v exportSequence
66
{"displayName": "Karel Poláček",
"uuid": "456af2dd-0783-44f6-9984-2d9d09baf41b",
"name": {"familyName": "Poláček", "givenName": "Karel", "displayName": "Karel Poláček", "sync": "7497ada0-ffa2-42b9-be96-38fba9d56d88", "primary": "false"},
"event": [{"sync": "ccb515f3-2d80-498c-9ae6-b256e9ee93e8", "type": "birthday", "value":
"1893-03-22", "primary": "false"}],
"email": [{"sync": "9fee2628-76f5-43f4-b7d7-b11bbe9c01cf", "type": "home", "value": "[email protected]", "primary": "false"}],
"phone": [{"sync": "9c258986-ef2f-4ef2-a80d-401107267ab8",
"type": "work", "primary": "false"}],
"value":
"222-323-983",
"urls": [{"sync": "752921fb-ced8-4563-95b0-bd91c7dcf3d9", "type": "profile", "value":
"http://cs.wikipedia.org/wiki/Karel_Polacek", "primary": "false"}],
"im":
[{"sync":
"adccda29-cf68-4712-bae3-3749ab2dea99",
"value":
"[email protected]", "protocol": "googleTalk", "type": "home", "primary":
"false"}],
"sipAddress": [{"sync": "0d7211cd-5be2-4c0f-ad53-ec3586f20ce4",
[email protected]", "type": "home", "primary": "false"}],
"value":
"ka-
"addresses": [{"sync": "4dafb46f-8ba4-4852-b945-ec938f166595", "region": "Praha", "streetAddress": "Koněvova 343", "postalCode": "11022", "primary": "false", "neighborhood": "Žižkov", "type": "home", "city": "Praha", "country": "Česká republika"}],
"organization": [{"sync": "03800363-8964-44c9-b419-bc29cd4787f2", "title": "sloupkař",
"type": "work", "department": "denní tisk", "primary": "false", "company": "Lidové noviny"}],
"note": [{"sync": "99972fd1-7e27-4308-9375-f51b76f42a00", "note": "Má 4 bratry: Arnošta,
Kamila, Ludvíka a Zdeňka", "primary": "false"}],
"nickname": [{"sync": "f42e1dbc-73a3-4dac-9eff-716f445c8178", "value": "Polič", "type":
"default", "primary": "false"}],
"photo": [{"sync": "1d3ff9db-3b4e-4c9b-ac85-9c96fe07667d", "photoName": "karel.png",
"primary": "true"}]}
Tabulka B.1: Kontakt v JSON podobě se všemi podporovanými atributy
Příloha C
Instalační příručka
Pro správnou činnost doplňku je doporučováno používat Mozilla Thunderbird ve verzi
11.0.1 (v době psaní této příručky nejnovější verze). Zásuvný modul se instaluje ze souboru ExtBrainSync.xpi, který najdeme na přiloženém CD.
C.1
Instalace
1. Otevření Nástroje -> Správce doplňků v aplikaci Mozilla Thunderbird.
2. Přetažení (drag&drop) instalačního souboru ExtBrainSync.xpi do tohoto správce.
3. Potvrzení instalace.
4. Restart aplikace Thunderbird.
C.2
Vytvoření účtu
1. Kliknutím pravým tlačítkem na složku kontaktů v adresáři otevřete kontextové menu
a zvolte „Add ExtBrain Sync accout“, otevře se průvodce vytvořením účtu.
2. Klikněte na „Create new“. Zadejte přihlašovací údaje k IMAP serveru, jeho adresu a
typ zabezpečení (SSL nebo TLS) a potvrďte kliknutím na „Další“.
3. Vyberte složku, kam chcete kontakty synchronizovat, nebo zadejte název nové složky.
4. Účet se vytvoří kliknutím na „Další“.
V případě, že jste již zadali přihlašovací údaje k IMAP serveru, nemusíte je při vytváření účtu k jiné složce zadávat znovu, ale ve druhém kroku lze vybrat ze seznamu již
registrovaných serverů (viz obrázek C.1).
Seznam všech vytvořených účtů můžete zkontrolovat v okně „Možnosti ExtBrain Sync“.
Toto okno se otevírá ve Správci doplňků. V možnostech najdete také tlačítko na vyčištění
složky s fotografiemi kontaktů.
67
68
PŘÍLOHA C. INSTALAČNÍ PŘÍRUČKA
Obrázek C.1: Úvodní okno průvodce pro vytváření účtů
Obrázek C.2: Okno se seznamem složek na serveru
C.3. SPUŠTĚNÍ SYNCHRONIZACE
C.3
69
Spuštění synchronizace
Synchronizace se spouští kliknutím na „Start sync“ v kontextovém menu složky kontaktů. Po
spuštění se otevře okno s informacemi o synchronizovaném účtu a probíhajících operacích.
Po dokončení synchronizace zavřete toto okno tlačítkem „OK“.
Obrázek C.3: Spuštění synchronizace
70
PŘÍLOHA C. INSTALAČNÍ PŘÍRUČKA
Příloha D
Obsah přiloženého CD
ExtBrainSync
text
ExtBrainSync.xpi
readme.txt
<DIR>
<DIR>
projektový adresář se zdrojovými soubory
adresář s textem této práce (zdrojové kódy LATEXu i pdf)
instalační soubor zásuvného modulu
instalační informace
71

Synchroniza£ní modul pro Mozilla Thunderbird - ExtBrain

Transkript

Podobné dokumenty

Implementace protokolu XMPP v JavaScriptu

P°íloha E Instala£ní a uºivatelská p°íru£ka

Modul pro £tení zpráv pro Android

Monitoring KT 16

Integrace a rozvoj roz˛í°ení ExtBrain Communicator

Rozs20 s19 r20 ren19 ExtBrain Communicatoru o dals20 s19

České Vysoké Učení Technické v Praze Fakulta