Vezmu to od podlahy. Když Linux byl ještě miminem a krachující Windows 3.0 běžely jen na izolovaných počítačích, běžní uživatelé neměli o síťové komunikaci ani zdání. Větší firmy měly z čeho vybírat, ale domácí počítače byly mimo mísu – sítění bylo drahé. Začátkem devadesátých let přijuchaly Windows for Workgroups (později značené jen číslem verze 3.11) a milióny lidí překračovaly práh do světa sítí.
Producenti softwaru pro Windows se museli přizpůsobit. Místo toho, aby uživatelé přetahovali obsahy databází „podpažním systémem“ (disketou), mohli ze svého počítače komunikovat s databází umístěnou na jakémkoli jiném počítači v lokální síti (brzy přibyl i komunikační modul TCP/IP). Nadšení neznalo mezí. A to ještě neexistoval webovský prohlížeč a Internet byl záležitostí podivínů, píšících nějaké hieroglyfy do příkazové řádky.
Když tak vzpomínám na to, jak jsem v síti W3.11 instaloval databázový software Paradox tenkrát slavného Borlandu a koukal, co a jak se děje, musím konstatovat, že historie se stále opakuje. Sice v jiných rozměrech, ale podstata zůstává stejná. Tenkrát stačilo, abyste na disk počítače v síti W3.11 uložili maličký soubor pdoxusrs.net a měli jste přístup ke všem paradoxím databázím na síti. GUI zajišťovala okrouhaná klientská verze (na tom se zase tak moc nezměnilo). Kompozitní GUI tenkrát nikoho netrápilo – už proto, že přenos dat byl pomalý i v LAN (procesor 386 byl výkřikem módy).
Skoro totéž teď řeší vývojáři MS.NETu a jiných podobných internetových projektů. Jedním ze zásadních problémů je, co se bude provádět u klienta a co na serverech APS, k nimž se budou klienti připojovat. V houštině hledaných řešení je i hezký logický problém – která data bude kdy vhodné poslat klientovi, aby se s nimi žonglovalo u něj a nezatěžovaly se tím servery (samozřejmě včetně zajištění přenosu výsledků operací s daty z klienta zpátky na servery APS).
Na to přímo navazuje otázka – co bude u klientů provádět tyto operace s daty (a kdy a jak se změny přenesou na servery, aby nezmizely)? Klientské provádění operací s daty zaslanými ze serverů není nic nového. Stačí připomenout nejen prostou interpretaci HTML či JavaScriptu, ale i javový JVM apod. A co takhle zašoupnout do klienta CGI (resp. API), které bude dělat s daty to, co s nimi CGI dělá na serverech?
Tuhle – zdánlivě bláznivou – myšlenku mi vnukl experiment otevřeně kódové skupiny geeků Protozilla. Podoba jejího názvu s polo-netscapovskou Mozillou není náhodná. Kluci v Protozille vyvíjejí udělátka pro prohlížeč Mozilla. Protozilla se ale nezabývá jen CGI. Její architektura umožňuje práci s jakýmkoli protokolem přímo z prohlížeče. Stačí zadat příslušný řetězec znaků – hlavně prefix – do URI (adresové části prohlížeče) a už to jede. A nejde jen o lokální využití. Spustit software na klientovi via URI lze i zvenčí (pokud je to povoleno), stejně jako spustit komunikaci via URI z klienta směrem ven. Protozillový software není věrnou kopií systému plug-ins pro prohlížeče – vývojáři Protozilly svému postupu začlenění softwaru s předurčenými funkcemi říkají „socket adapter“.
Protozilla sleduje dva zásadní trendy. Prvním je snaha nacpat veškerou komunikaci do prohlížeče. Možná si vzpomenete, jaké haló před lety vyvolal Microsoft, když do MSIE začlenil i (odkliknutelné) výpisy obsahů lokálních disků. Já jsem už před pěti lety začal využívat databázový skriptový jazyk á la SQL a pro komunikaci se svými daty via CGI WWW serveru, abych nemusel používat otravné GUI databáze. Od té doby znám jen její nejprostší tabulkové provedení a všechno se mi zobrazuje v prohlížeči. I proto tak chápu snahy integrovat veškerou komunikaci do prohlížeče a fandím jim.
Druhým trendem Protozilly (a nejen jí) je přesun operací s daty ze serveru na klienta. To má své limity, ale i možnosti. Samozřejmě, že se na klienta nepřesune obsah obří databáze s milióny položek jen proto, aby mohlo přijít ke slovu jeho CGI. Ale např. komunikace ve skupině lidí, kteří budou využívat databázi (aniž to třeba tuší) zcela mimo server, je nabíledni (replikace a další řízení toků dat v takových databázích je samozřejmostí). Stejně tak si lze představit přesun části dat databáze ke klientovi, u něhož už všechno na sebe vezme jeho CGI, včetně osobního i externího doplňování databáze, jejích úprav apod. A to vše velmi svižně. Což otevírá i pole pro finanční kompenzaci poskytnutých dat – např. u vědeckých databází. A i když skoro všechno na světě jsou databáze, nemusí jít jen o ně.
Když opustíme pole poněkud natvrdlých webovských serverů a skočíme do sítí peer-to-peer, pak se fantazie může rozvinout naplno. Různé protokoly, popisy dat, různá CGI/API u klientů se v těchto sítích mohou uplatnit měrou netušenou. I Protozilla se zaměřuje na sítě peer-to-peer, byť na svém počátku zatím jen na úrovni běžné klientské komunikace, resp. jejích základních protokolů.
Umožit klientům těchto sítí rozličné operace se získanými daty přímo u sebe, resp. na serverových „nodes“, by byla pohádka (i pro hackery :-) Stejně tak možnost využití „socket adaptérů“ pro prezentaci svých dat v síti peer-to-peer, by byla (a snad bude) lahůdkou. Funkce takových adaptérů by mohly přispět k řešení problematiky neotravné kompenzace autorských děl, rozvoje aukcí a jiných prodejů via peer-to-peer, zajímavých forem interaktivní komunikace ve skupinách, relevantnějšímu prohledávání opravdu aktuálních dat atd. Inteligentní vývoj softwarových adaptérů by mohl vést i k jejich standardizaci a posunu kupředu především v sítích peer-to-peer.
V září jsem pro Lupu napsal článek Musí být GUI trvale na desktopu? Ale vůbec ne. Jak nato?. Klientské softwarové adaptéry pro peer-to-peerovou komunikaci z prohlížeče možná pootevřou vrátka kompozitním GUI o něco víc. I když se trend, jaký nastoupila Protozilla, zčásti objevuje i v uzavřeném – a vzájemně nekompatibilním – kódu velkých firem (Microsoft, Apple), vývoj otevřeného kódu přináší větší šance jeho obecnějšímu uplatnění. Bohužel, otevřený kód se dělá, jen když je čas a chuť, takže to jde pomalu, byť hezky. Důležité ale je, že takový vývoj tady je a že ho může převzít a rozvinout, kdokoli bude mít chuť a dobrou vizi.
ČLÁNKY DO MAILU