Navrh komunikace mezi moduly projektu a jejich funkci na zaklade druheho
setkani - druha verze:

Formularnik:
    1. pozadavek bude obsahovat nejaky udaj podle ktereho bude mozne zvolit sablonu
    a vratit podle ni formular. Tento formular bude obsahovat skryte polozky
    bud definujici sablonu nebo pripadne primo zbytek jejiho obsahu.
    Alternativne bude jediny mozny prvni pozadavek ("obsah"), ostatni
    sablony (primo/kod) tedy prijdou od planovace jako reakce na predchozi.

    Po vraceni formulare se podle techto zbylych dat sablony provedou zakladni
    kontroly (polozka je/neni, je cislo/neni) a data prerovnaji do formatu
    zakladniho zaznamu.
    
    Mel by byt schopny postarat se o vsechny zalezitosti spojene se znakovou
    sadou, nebot ma spoustu informaci k jejimu uhodnuti (ktere by bylo zbytecne
    posilat dal).
    
    Ten se odesle planovaci (pri zadavani dat bude jejich soucasti vlajka
	vyjadrujici status, tj. ze je to prvni pokus).
    
    Pokud nedostane odpoved (nedostane vcas - timeout) vrati alespon to co zjistil
    sam (a varovani)
    
    Odpovedi je obecna HTML stranka - muze to byt formular podle stejne nebo jine
    sablony nebo jen tabulka vysledku.

    Hlavni funkci formularnika je nespadnout, tj mel by uzivatele upozornit
    na vysledek i v pripade ze v dusledku chyby nebo pretizeni serveru neni
    mozne pozadavek plne vyhodnotit. Muze vracet refreshe (data se vyhodnocuji,
    pokud nemate zapnuty javascript kliknete za 20 sekund sem). To ovsem pouze
    v pripade nepouziti primeho volani ...
	Mozna by pri podobne prilezitosti mel kontaktovat spravu dat, zvlast
    pokud ta se naopak bude volat primo, a ulozit nezkontrolovana data.
    Pokud se bude sprava dat volat neprimon neni jiste zda ma smysl - nastavit ?

    Vyhodou tohoto pristupu z druhe strany je fakt, ze pokud uzivatel zavre
    browser, muzeme formularnika shodit a nechat bezet pouze planovac ...

    JAVASCRIPT: Prvni napad k cemu je dobry - muze ridit pocet poli v pripadech,
    kdy ma smysl posilat soucasne vetsi mnozstvi zaznamu. V tomto a podobnych
    pripadech by mel totez byt schopen udelat formularnik sam bez planovace
    (pro pripad vypnuteho javascriptu). Z toho je mimochodem videt ze sablona
    nemuze byt prosta HTML stranka obohacena o jmena promennych. Pravdepodobne
    se bude jednat o XML dokument.

Import:
    Rozdeli vstupni data na jednotlive pozadavky a nasazi do planovace.
    Nic komplikovaneho, krome vlastniho vstupniho formatu.
    
    V pripade zakladnich zaznamu asi ani nema smysl posilat vic najednou,
    jinak je tomu v pripade update pomocnych dat - ty budou mit pomerne male
    zaznamy.

Startovac - mail:
    Opet nic komplikovaneho. Pro pripad ze to bude pozdeji vyzadovano nezapomenout
    ze k zadavanym datum musi pripojit emailovou adresu ze ktere prisel mail
    (resp. reply-to) a ze muze byt pozadan aby na ni neco poslal.

Planovac:
    Data z formulare/startovace/importu:
	ZZ: posle do databaze, tim si obstara jednoznacny klic a posle testeru.
	Vlastne muze testeru poslat pouze klic, tester ani nektera data nemusi
	tahat z databaze nebo na nich muze pracovat primo v databazi.

	OSTATNI: dokonce ani v pripade hledani patrne nema smysl posilat
	do databaze ... dat bude relativne malo a nebudou pasovat do struktury.
	Obvykle bude nutne poslat je do testeru - nema smysl sacovat databazi
	na vsechny zaznamy z fakulty se zkratkou MMF ... to bude prace pro
	modul testeru ktery by mel opacit "Nemyslel jste nahodou MFF ?"
	Rovnez autentifikace muze byt soucasti testeru.
    Z testeru dostane odpoved "zpracovano", patrne bude vse v databazi.
    Posilat skutecna data ma smysl pouze pokud je spojeni tester-planovac
	rychlejsi nez planovac-databaze. Planovac posle data zpet volajicimu
	modulu - pokud neni jasne s metody komunikace, jako ze asi bude,
	bude kod modulu uveden v datech. Pokud nema volajici o data zajem,
	at si je ignoruje sam.
    Pokud bude nejak schopny zjistit ze je stroj pretizeny, muze nektere
	kontroly vynechat ...
	Otazka: bude tester jedina aplikace, nebo se bude jednat o balik
	modulu a planovac bude primo rozhodovat ktere se zavolaji ?
	V pripade pomaleho spojeni dost nepohodlne ... 

Tester:
    jeho funkci je provest slozitejsi kontroly. Bude tezce pracovat s databazi
    (spravou dat) - vyzvedne seznam kontrolu typicky se vztahujici k nejake
    tabulce (a hodnote formulare) a bude je provadet a oznacovat do ZZ vysledek.

Export:
    mohl by byt resen kompatibilne s formularnikem - tj posle pozadavek na
    vyhledavani a pote zpracuje vysledek a nasklada do pozadovaneho formatu.
    Alternativne prvni cast - pozadavek na vyhledavani - posle formularnik
    s tim ze export bude volan na vysledna data pouze pro naskladani do souboru
    v pozadovanem formatu.
    Vysledny soubor by mel byt nabidnut k downloadu - coz vede k otazce
    kdy a kdo ho smaze. Pokud bude vytvoreni exportu relativne casove narocne
    (coz asi bude), asi bychom meli nejen posledni ponechavat na miste dokud
    nebude nahrazen novejsim, ale dokonce davat pozor na zmenu dat a pokud
    od posledniho exportu stejneho typu zadna nebyla, vratit posledni export.

Sprava dat:
    dostane jednoduse dotaz - tj vetsina polozek klic/hodnota bude primo
    nazev udaje/hodnota pro dotaz, dalsi polozky budou pouzita tabulka
    a zda se jedna o select, update/insert nebo init (vytvor vsechny pozadovane
    databaze bez obsahu).
    Prepise do SQL (prip do jineho dotazovaciho jazyka :-)) podle parametru
    databazoveho serveru kteremu bude dotaz polozen, zavola rozhrani a z odpovedi
    vytvori stranku (ne nutne HTML).

    Parametry dotazu (jine nez udaj/hodnota)
	metoda - SELECT/UPDATE/INIT
	Kam vratit data - pokud nebude jasne z pouzite metody komunikace
	    (jako ze asi bude)
	tabulka - nemusi jit primo o nazev, i kdyz me nenapada proc.
	overovaci udaj - napr. MD5(klic.ostatni_data)
			 Pokud nebude sedet, predpoklada se ze dotaz je falsovany.
			  => Neprovest, logovat. Vcetne IP. I kdyz ... pozadavek
			  z jine IP by mel byt povazovan za padelek rovnou ...
		Nenapada me duvod pro pouziti slozitejsi metody overeni.
		I kdyz posilat data sifrovane 2048bitovym asymetrickym klicem
		pro kazdy modul a den jiny ma take neco do sebe ... :-)
		
		Pouzity klic musi byt soucasti kazdeho modulu bud primo,
		nebo neprimo - napr. muze byt castecne urceny z adresy serveru,
		nebo vytazeny z databaze pod jinym klicem specialne pro tento
		ucel. Patrne by mel byt includovany, stejne jako heslo
		k databazi v databazovem programu, z duvodu snazsi spravy.

Navrzene metody komunikace:
    form - formular
	ZZ - zakladni zaznam
	Q - databazovy pozadavek

    lidi-formularnik: form
    formularnik/import/startovac/export-planovac - (direct call,) form (ZZ)
    planovac-tester: direct call, form(ZZ)
    formularnik-spravaDat: direct call, form(Q) = tahani sablony
    tester-spravaDat: direct call, form(Q)
    planovac-spravaDat: direct call, form(Q=ZZ)
    spravaDat-databazovaRozhrani: direct call

Data - predpokladam ze vsechny budou v databazi. V extremnim pripade mozno
    mit v databazi i kody modulu - pro testery by to melo i smysl.

    databaze sablon formularu
    databaze zakladnich dat, prip. nekolik databazi se stejnou strukturou
    pomocne databaze pro tester - seznamy authorit, zkratek, ciselnik oboru ...
    autentifikacni databaze
    databaze logu - nektere budou generovany jen pri testovacim provozu, nektere
		    porad.
    databaze IP - ktere IP adresy maji jine nez default pravomoce
		    - napr. pravomoc posilat dotazy databazi.

Poznamky:
    Vyhledavani bude v zasade take zakladni formular
	- budou zadany zname udaje, fakt ze pozadujeme vyhledani bude atribut.
	Nektere formulare takovou podobnost mit nebudou, otazkou je zda bychom
	je i tak nemeli resit podobne - jak velka by byla takova univerzalni ZZ ?
    Pri pouziti formularoveho volani spravyDat bude zapotrebi formular zabezpecit
	klicem a podpisem (MD5)
    Da se predpokladat ze nejcastejsi operaci bude hledani, druhou nejcastejsi
	vkladani (resp. aktualizace) ZZ. Leda ze by nekdo pouzival mechanismus
	stiznosti misto diskusniho serveru.

Dale poznamky ze setkani:
1)  Ani v pripade formulare se neda predpokladat ze budeme schopni sezrat vsechny
    data - napriklad pokud nekdo do kolonky telefonni cislo (uklada se neco takoveho ?)
    pracne opise adresu, neni smazani (neni to cislo) spravna reakce.
    O zadavani mailem nemluve.
    Proto bude ZZ obsahovat polozku "ztracena data" do ktere se nahazi veskery
    srot pro pripad, ze by ho uzivatel chtel pastovat kam opravdu patri.
    Pochopitelne, taky si tam muze schovat URL k nejake slecne kterou zrovna
    nasel na webu ... coz me vede k zaveru ze by se tyto data meli ukladat
    zvlast peclive ...

2)  Logovat, logovat, logovat. Kam jinam nez do databaze. Jedine co ma smysl
	logovat jinam - napr. s pomoci webserveru - je informace o tom ze
	databaze neco zvorala ...
3)  Testovat, testovat, testovat.