Správa kontaktov, diár a úlohy v Linuxe
Jak na správu kontaktů, diář a management úkolů pod Linuxem? Ano, existuje
pár částečných řešení, ale je tu i AMP, tedy bude tu AMP!
Pokiaľ si ale myslíte, že je to niečo ako Outlook, tak sa asi mýlite, tradične v Linuxe
su to riešenia z inej strany problému. Článok mám zo servera REBOOT.CZ
AMP neznamená nic jiného než Advanced Management Protocol. Jedná se o
OpenSource projekt, který si klade za cíl vydefinovat doporučení
síťového protokolu a uvolnit jeho referenční implementaci. Celý projekt
probíhá pod BSD licencí a s podporou elfů, tedy skupiny okolo elfove.cz. Než přistoupím k nástinu
toho, co považuji na protokolu a jeho referenční implementaci zajimavé,
nebo chcete-li netradiční, a k popisu plánů, musím důrazně upozornit,
že, jak by řekl Cimrman, největší
objevy jsem učinil já…
Co mě
vedlo k úvaze o novém protokolu?
Prostě to tu ještě nebylo. To, co umí Evolution, o 15 let starých
výplodech společnosti Microsoft, na které se Evolution váže, ani
nemluvím, je jen slabý odvar toho, co bude umět AMP. Prozkoumal jsem
stav okolo KDE a jeho vlastní architektury, jež řeší velmi podobný
problém (vývoj sponzoruje Německá vláda a není mi jasné, jaký profit z
toho bude mít či jaké nároky pak bude na software uplatňovat). A došel
jsem k závěru, že ani jedno z nich se nemá šanci stát opravdovým a
konečným řešením problému pro malou rozšiřitelnost a jistou strnulost,
podobnou výše zmíněné architektuře Microsoftu. Příkladem aplikací,
které sice nejsou nejsou vyhovujicí, ale blíží se funkčností mé idei,
byla jedna komerční aplikace napsaná v PHP, kterou jsem viděl na jisté
prezentaci (za cca 30 kKc za firemní licenci), nebo známé PHP GroupWare
(http://www.phpgroupware.org).
Jejich společným problémem je vázanost na webové rozhraní a z jeho
podstaty plynoucí nemožnost off-line přístupu. Krom toho malá flexibila
a vázanost na platformu serveru, špatná rozšiřitelnost a tak dále. Jako
primární cíle jsem si stanovil bezpečnost, škálovatelnost, snadnou
rozšiřítelnost o další moduly a funkce, možnost přístupu nejen
klientskou aplikací, ale také přes webové rozhraní a přes WAP, případně
SMSky a mailového bota.
Z čeho
protokol vychází?
Především z rozšířitelnosti na všechny možné oblasti řízení, proto
jméno Advanced Management Protocol bez spcifiace toho, co se vlastně
řídí. Původní projekt se jmenoval ATMP (Advanced Time Management
Protocol) ale později, když jsem o architektuře protokolu přemýšlel,
vypustil jsem ono „Time“ a rozhodl se jít s abstrakcí poněkud hlouběji.
Vycházím z toho, že protokol má být otevřený a čitelný a proto je jeho
základem XML. Dále z toho, že už existuje LDAP a proto kontaky budou
řešeny pouhým front-endem pro LDAP na straně klienta a samotný AMP se
zaměří na problém řízení a optimalizace využívání zdrojů. Vychází z
toho, nebo spíše uvažuje s tím, že jeho data budou uložena v SQL
databázi, ale když nebudou, tak se nic nestane. Pro referenční
implementaci byl zvolen jazyk Java a to pro serverovou část, tak i pro
klienta. Referenční implementace je nyní (na přelomu roků 2002 a 2003
zhruba ve třetině až v polovině implementace serverové části a
plnohodnotný textový klient, vhodný na ladění a pro guru, kteří GUI z
náboženských důvodů odmítají, je již na světě. Další vývoj bude záviset
na chuti učit se dělat GUI a ev. na participaci dalších lidí. V
okamžiku, kdy bude hotový server upřu totiž síly především na vývoj
webového interfacu, což bude opět pouhý fornt-end pro textového klienta.
Referenční
implementace
Jak jsem již předeslal, k referenční implementaci je použita Java. To
má značné výhody a ušetří to spoustu práce. Mnozí z Vás asi doplní „jo,
ušetří si práci… na úkor výkonu“. Dobře, je to tak, ale je to pouze
referenční implementace a tedy se od ní nežádá výkon, ale jen aby to
fungovalo a aby byla čitelná. Pro to je Java jak stvořená. Každá
příchozí zpráva je vždy přeparsována standardní Javovou knihovnou na
zpracování XML dokumentů. Jako nejvhodnější se mi připadnul DOM model.
Jeho podstatou je předání XML dokumentu engine DOM, který z něho
vygeneruje strukturu objektů, reflektujicí řečený XML dokument. Tato
struktura je pak předána enginu protokolu, který z ní vyrobí příslušnou
Message a předá ji enginu daného serveru respektive klienta, který ji
zařadí do fronty ke zpracování.
Message
model, XML, referenční implementace
Java se přímo nabízí pro model, který jsem, po úvaze, odpovídajicí
délky, zvolil. Idea referenční implementace vychází z XML reprezentace
Javových objektů odvozených od mnou definovaného interface Message. AMP
neimplementuje mechanismus ani nedefinuje rutiny pro konverzi Javových
objektů na XML a naopak. Toto je jen v režiji referenční implementace,
protože mi to přišlo jako účelné. Tedy AMP, jako protokol, definuje
základní strukturu Message, což je esenciální objem dat, který sám o
sobě obsahuje informaci o tom, že je Message a udává verzi protokolu. V
podstatě to je velmi jednoduchý XML dokument obsahujicí bratru 5 řádek.
Dále je definována základní sada messagí odvozená od Message, která už
nesou nějaká užitečná data. Tato základní sada messagí řeší přihlašování
k serveru, autentizaci uživateů a ošetřování chybových stavů.
Filosofie, v rámci referenčí implementace, jde však mnohem dále.
Vzniklo rozhraní MapedMessage, které kromě informace o majoritní verzi
protokolu nese informaci o okruhu, do kterého message zapadá. Vzniknou
tak okruhy MapedMessagí, ketré se mohou distribuovat jako samostatný
balíček a na straně klienta i serveru se prostě jen přidají a
zaregistrují do systému. Registrují se přes třídy, která implementuje
rozhraní Map. Rozhraní Map definuje několik esenciálních metod pro
popis universa MapedMessagí v daném balíčku. Každý klient či server si
instaluje potřebné balíčky s příslušnými okruhy a zaregistruje pomocí
konfiguračního souboru jejich Mapu. Používat jednoduché Message je
považováno za nedoporučené, leč možné a identifikator Mapy „0“ je
ekvivaletní wildcartě. Samotné rozhraní message není nijak zajímavé a
od něj odderivované esenciální třídy jen definují jak musí vypadat
uživetlské třídy aby je byla schopna zpracovat Engina serveru a poslat
přes síť. Tolik k referenční implementaci a k využití vlastností Javy.
V konečném důsedku, bude-li implementovat některou verzi protokolu a
určité okruhy Messagí někdo jiný, může klidně postupovat úplně jinak.
Protokol se omezuje na definici struktury Messagí a pak na jejich
konkrétní definici v rámci okruhů.
Serever/client model v ref. implementaci
Model server client Javou může poněkud utrpět. Java totiž svádí k tomu,
aby byly uživatelské sady messagí stejné pro server i pro klient. Tedy
aby implementovaly funkce pro obojí a ušetřila se tak námaha se správou
dvou stromů navzájem datově kompaktibilních tříd. To ovšem není vůbec
zdravé pro filosofii ani pro samotnou implementaci. Nezakazuji napsat
jednu sadu tříd poplatnou pro serverovou bázi i pro klientskou bázi.
Lepší ovšem je napsat dvě sady Messagí a v jedné bázi implementovat
rozhraní ServerBase a v druhé ClientBase. Tato rozhraní popisují, jak
budou přijduvší Message zpracovány na které straně. V případě serveru
je filosofie taková, že server zpracuje Message, vytvoří její platnou
instanci a zavolá její metody, které jsou definovány v rozhraní
ServerBase. Server poskytne Messagi rozhraní reprezentované třídou
Kernel, který implementuje všechny podstatné funkce serveru. Poskytne
výkonné části Message rozhraní pro přístup k databázi, pro volání
dalších součástí serveru, především runtime části a ke geneátoru
identifikátorů, kteří slouží ke generování dalších Messagí (odpovědí) a
jejich zařazování do front k odeslání či dalšímu zpracování. Idea je
tedy v podstatě taková, že každá Message, jakožto reprezentace v Jave
nebo jako XML dokument bude obsahovat jednu nebo více otázek, odpovědí
či chybových hlášení. Každá Message bude označena svým identifikátorem
a ponese indetifikátory souvisejicích Messagí. Takže v případě
jednoduché otázky ponese pouze svůj vlastní identifikátor, v případě
jednorázové odpověďi ponese identifikátor otázky a také svůj vlastní.
Takhle budou uzlu sledovat souvislosti mezi zprávami. Ačkoliv by
protokol měl být bezstavový, tato možnost zde pořád zůstává.
Plány do
budoucna
Plány jsou v součastnosti takové, že prioritu má vývoj serveru, dále by
pak mely být rozšiřovány okruhy Messagí nejen pro diář, ale i pro řízení
projektů, záznam odpracovaných hodin, společné úkoly, plánování pro
team a podobně. Především jakmile bude celá architektura implementována
tak upravím celou komunikaci pro zajištění bezpečnosti. Pro tento účel
bude použita některá standardní implementace asymetrické kryptografie a
už od začátku se s tím počítá, takže to nebude žádná křeč jako u jiných
protokolů. Další zajímavou možností je automatické sjednání schůzek,
kdy na požadavek na schůzku najde server vhodný termín pro oba
zůčastněné a pošle se jim žádost o schůzku, kterou oba potvrdí a tím se
jim schůzka naplánuje. Také umožňím zrušit schůzku pro oba zúčastněné,
pokud jeden z nich podá žádost o zrušení. Vrcholem AMP by však měla být
dostupnost. To, proč kladu tak malý důraz na klientskou aplikaci
souvisí s tím, že dalším bodem plánů jsou AMP2WWW a AMP2WAP bridge.
Mají zajistit onu tolik žádanou a podstatnou funkci přístupu přes
webový prohlížeč a přes WAP. A posledním bodem by měla být SMS a
později jednoduše GSM gateway, která se bude využívat k notifikaci o
blížicích se schůzkách a podobně SMSkami a nebo třeba k buzení
telefonem. Její využití se dá ale předpokládat především u komerčních
provozovatelů služeb AMP, proto má tak nízkou prioritu ačkoliv je tato
služba ze všech nejzajimavější.
Zaujal Vás
AMP?
Chcete spolupracovat? Máte zájem o další informace? Napište mi a nebo
kolegovi Jiřímu Tlapákovi. Protocol draft by měl být v nejbližší době k
nalezení na ftp serveru a plánuje se CVS, časem se také objevíme na
SourceForge. V součastnosti ale není protocol draft úplně dopsaný a na
implementaci se horečně pracuje. Na Internetu se nemusí vyskytovat
aktuální verze a v případě zájmu se proto doporučuji informovat mailem.
Informace
a adresy
WWW prezentace: http://www.elfove.cz/amp
CVS: :pserver:anmonymous@canis.elfove.cz
FTP: ftp://ftp.elfove.cz/pub/amp
maily:
