Historie: Pred davnymi casy v predalekem m@f#u bezela sluzba jmenem User Directory Service. Slo o jakysi "telefonni seznamy" s e-maily namisto tel. c., takze o jakousi databasi emailovych adres. Kdyz se zhruba ve stejne dobe Seznam.cz pokusil o obdobnou sluzbu, nabidli softwarovi magove z m@f#u poskytnuti sve database, neb preci jen za tu dobu ziskali slusne mnozstvi dat. Internetovy portal toto vsak odmitl s argumentem, ze se jedna o "konkurenci". Od tech dob je v mysli pana doktora Forsta postaven mentalni blok (jinymi slovy nesnasenlivost) vuci Seznamu obecne, proto toto slovo v jeho pritomnosti radeji vubec nevyslovujte a promenne ve zkouskove pisemce radeji pojmenovavejte "list".
Zadani: Implementujte databasi s polozkami:
Prikazy se zasilaji e-mailem (v 1 e-mailu max. 1 prikaz). Program dostane na svuj stdin mail ve formatu::E-MAIL (jakozto unikatni klic /
index)
:NAME (muze byt i vice nez dvouslovne - to poznamenal po povsimnuti meho
trojslovneho jmena:)
:DESCR (upresnujici popis o vlastnikovi adresy - pozor, muze byt i viceradkovy! Database si musi uchovat i puvodni strukturu textu se vsemi puvodnimi bilymi znaky to byl kamen urazu cele ulohy, neb nejde jednodusse pouzit /etc/passwd "dvojteckovy" format db)
Ma-li dopis spatny format (napr. UDS cast uplne chybi), zasle se odesilateli o...
hlavicka mailu, dulezita je jen polozka odesilatele
From: jmeno@domena.tld
- za "From:" je mezera a rovnou adresa (zadny MIME garbage - velke usnadneni:)
- automaticky se ignoruji jmena (konkr. predzavinacova cast) pritomna v systemove promenne "REJECT" (takovy blacklist)
...
hlavicka oddelena od tela mailu prazdnou radkou
> ...
> telo mailu
> jak je videt, muze obsahovat i "reply zobacky", to quli automatickym odpovedi
> na potvrzovaci klice (viz nize) -> tech je treba se zbavit!!!
> ...
> prikaze pro UDS (vzdy jen jeden) vypadaji takto:
UDS PRIKAZVELKYMIPISMENY tretiparametr
:NAME moje jmeno
:E-MAIL moje@jmeno.fb (chybi-li, pouzije se udaj z From: hlavicky)
:DESCR slovni popis, a to
_muze byt
_i
_nekolikaradkovy
_ovsem vzdy zacinajici mezerou (zde videt jako _podtrzitko_, forum mi mezery maze)
Toto jiz neni soucast popisu (nezacina mezerou). Tudiz i prazdny radek uz nepatri k popisu (opet nezacina mezerou) a chce-li ho klient v popisu, musi napsat mezeru a odradkovat!
...
tom zprava.
Podporovane operace (viz PRIKAZVELKYMIPISMENY):
Kód: Vybrat vše
ADD - zkontroluje, zda-li adresa neni v db zanesena, a prida ji
Kód: Vybrat vše
REP - nahradi udaje zaznamu (resp. jen nekterou cast, je-li zadana k nahrazeni jen nejaka z polozek zaznamu)
... zde je nutne zavest bezpecnostni prvek = jednorazovy potvrzovaci klic.
Situace:
1) v db u zaznamu neni klic, v textu mailu tez ne -> vygeneruj dostatecne
nahodny klic (neda se predem odvodit), zapis si ho k e-mailu v db a posli tento
klic na adresu editovaneho zaznamu
2) v db u zaznamu je klic, shoduje se klicem v mailu -> uspesna nahrada
3) v db u zaznamu je klic, neshoduje se klicem v mailu / v textu mailu neni
NEBO
v db u zaznamu neni klic, v textu mailu je
(proste jde o jakykoli nesoulad)
-> zprava o nesouladu, smazani potvrzovaciho klice z db
Kód: Vybrat vše
DEL - smaze zaznam (staci bez potvrzeni, bezpecnostni prvek uz je pouzit u REP, bylo by to v podstate stejne)
Kód: Vybrat vše
FIND - zadana !1 polozka, dle ktere se vyhledava, !1 regex/wildcard (podle
naseho uvazeni), ktery se matchuje. Muze se tedy vyhledavat i v "descr",
coz trochu ztizi celou situaci, ale samozrejme to zalezi na konkretnim
navrhu.
spatny klic, a t.p.).
Kterakoli polozka muze chybet - v zavislosti na pouzitem prikazu to, co lze
rozumne vynechat (napr. ADD, DEL, REP by meli vzdy obsahovat mail, pod FINDem z
principu nemusi byt nic), v takovem pripade se defaultne pouzije stara hodnota
z db.
Melo by se pocitat s behem i 2 a vice instanci programu najednou, k db smi mit
v kazdem okamziku pristup jen 1 (jinak bude vse nekonsistentni - viz predmet
Databasove systemy), takze pres nejake zamky/lockfily.