no ja nevim:( .. pridavat do *.deu souboru neco co tam vlastne vubec nepatri a este kuli tomu zavadet specialni vyjimky pro parsovani. ikonky muzou bejt stejne dobre oddelene, navic ten deu soubor pak pude mnohem lip editovat rucne, coz byl myslim jeden z duvodu proc ho neudelat v xml.
taky ty by zpravy klidne mohly bejt treba v souboru messages.txt a bylo by to mnohem prehlednejsi, nez zatahovat naky novy zbytecny prvky do syntaxe
takhle se v tom fakt za chvili nikdo nevyzna:(
u toho rsync serveru, je potreba najit nastaveni tak, aby se to vzajemne zpropagovalo v obou smerech - a novejsi prepsaly starsi verze souboru, a jeste exkludnout soubor ktery je na danem stoji emitovan - tzn. ze v tom miste se vklada deu soubor cloudu do abytku ostatnich, aby nekdo zvenku komu se podela cas u souboru nebo tam neco podstrci neprepsal vlastni soubor ktery ten cloud na svem rsync serveru emituje. Pisu to kostrbate doufam ze mi rozumite.
__________________
------------------------------------------
"WARNING: Do not look into laser with remaining eye"
Nevidim duvod proc delat nekolik ruznych parseru... Nesouhlasim s tim ze format je neprehledny. Ikonky vyresim tim ze se budou moct loadovat z ext. filu, ale o to jde? Mame tu dve skupiny prikazu (to se snad nekomu zda moc?):
<NECO>:<DATA>
sem patri atributy polozky v seznamu. Na tom se nic nemeni od puvodniho navrhu.
a
:<NECO>:<DATA>
Tady je definovano LOAD a MESSAGE. Load je tu proto, aby se dalo includovat dalsi soubory a nebyl v tom bordel.
Message je myslim dobrej napad jak informovat lidi.
ALE TED TO PODSTATNE:
Tu druhou skupinu VUBEC nemusis znat, protoze staci vytvorit soubor global-x.x.x.x.txt a skipt ti automaticky vytvori seznam kde bude :LOAD:global-x.x.x.x.txt.
Na pridavani zprav pro uzivatele lze taky udelat jednoduchej skript, ale nevim co na
:MESSAGE:nazev
...text..
:MESSAGE:END
je sloziteho.
Takze zaverem: moje rozsireni NENI na ukor prehlednosti, je to nastroj jak zprehlednit rucne psane soubory a jak dat pokrocilemu uzivateli dalsi moznosti.
Vytvorit zakladni soubor <NAZEV-VLASTNOSTI>:<DATA> dokaze snad kazdy.
Opravdu nechci predelavat jeden jednoduchy parser na tri jiny, kazdy pro jednu vec. To mi prijde jako pekna blbost. Srovnavat aktualni format s XML, to je jako srovnavat INI a XML.
Co uznavam jsou externi ikonky, takze to vyresim a implementuju.
zpravy nejsou zdrojem a stejne sou lokalni, tak holt bude o soubor vic
ikony pokud jednu pouzijes vickrat, tak je to pak zbytecnej prenos dat, navic nektery programy treba ikony vyuzivat nebudou, zakladni soubor by mel bejt co nejjednodussi a veci bych tam pridaval jako externi soubory
1. Reknu to jeste jednou IKONKY BUDOU V EXTERNIM SOUBORU. Tak to prestante resit...
2. Pokud ti vadi ze do DEU taham neco jako ":MESSAGE:" tak to ber jako JINY format, treba XYZ ve kterym bude index.txt a soubor se zpravami. Nic vic.
Programu to nevadi, ale pro uklidneni vas vsech: soubory cloudu (global-x.x.x.x.txt) BUDOU SMET OBSAHOVAT POUZE <keyword>:<hodnota>, ZADNE PRIKAZY, ZPRAVY, atd.
3. Na zpravy se BUDE pouzivat extra soubor (nic jineho sem nikdy netvrdil), v nem budou klicova slova ":MESSAGE:". Viceradkovy text nebude muset na kazde radce koncit "\" protoze kdo by se s tim tam dodelaval. Tohle ale ted nereste, protoze to NENI soucasti DEU souboru (viz vyse).
4. Na serveru bude existovat index.txt (opet NEBUDE v DEU formatu, pokud to chcete takhle) a v nem budou POUZE radky ":LOAD:global-x.x.x.x.txt" a pripadne ":LOAD:msg.txt".
Nikde nikoho nenutim aby jakykoliv jiny soubor parsoval jako DEU. To ze ja to tak delam je kvuli efektivite.
Automaticke hledani nejblizsiho serveru bude dosti inteligentni, ale to zverejnim az se tahle diskuze uklidni...
Ja nevidim duvod, proc by mel byt nejaky index.txt a v nem odkazy na dalsi soubory. Ja chapu se ze to preparuje lip nez obsah adresare, jeste k tomu vzdaleneho, ale timhle pridavas vec, ktera uz tam jednou je. Podle me tohle nema prilis opodstatneni. zda se mi lepsi stahnout si index.html, a postupne projet vsechny odkazy, pripadne je prohrat filtrem na regularni vyrazy, protoze indexy obsahuji linky napr. na sebe. Overit spravnou priponu, a muze se jet. Nezda se mi to zas tak slozite, aby bylo potreba mit extra LOAD. To uz je podle me o mnoho lepsi proste mit v tom indexu co radek to jmeno souboru, a cist to po radcich. Ale spis si myslim, ze je lepsi nacist primo adresar a stahnout to z adresare. Pro zacatek by se to dalo stahovat skriptem, a do programu to cist z lokalniho adresare.
Co se mi nelibi je ten format :NECO: zbytek radku. Jednak muj parser to nesezere (ne ze by byl problem to predelat), nebyl takovyto format na zacatku definovat, a obecne zaznamy vypadaji trochu jinak, vnasi to nekonzistentnost do souboru. Chapu ze casto chybi cesta, jak lidem sdelit, ze se neco bude dit, ale vnaset uplne jinou syntaxi do souboru se mi nezda vhodne.
Co treba to udelat tak, ze to bude normalni DEU zaznam, akorat bude mit TYP: MSG, treba subject v nazvu, telo zpravy v popisku. Zbyva akorat nekam hodit ten cas, kdy je to plane. Vzhledem k tomu ze to asi bude trochu specialni, by se to dalo hodit do tela zpravy oznacene nejakym specialnim symbolem. Treba na zacatku POPIS: TIME:54684264 Prvni veta zpravy. ... Vzhledem k tomu, ze by to bylo asi vice mene specialni pro tvoji aplikaci, tak bys to mel specialne pro tento pripad lehce slozitejsi. Jeste by to slo dat do data modifikace, ale tam by se nektere systemy mohly divit, ze tam maji cas z budoucnosti, kdyz je to cas modifikace. Kdyby to ta aplikace neumela, tak by to i tak zobrazila. Uzivatel by tam mel sice cosi navic, ale asi ne tak hrozne. Rozsah platnosti by se definoval v rozsazich ip adres, a bylo by vyreseno.
Ale myslim ze zpravy jsou vice mene nadstavba, ktera s puvodni sluzbou ma pramalo spolehliveho, takze by bylo lepsi kdyby byly sirene v nejakem extra souboru. Myslim ze na tuhle cinnost maji leckde uz davno zabehnute zpusoby, a myslim ze DEU je na to prilis pomalu aktualizovany. Sice to je zajimavy napad, ale souhlasim s klackem ze to primo do DEU nepatri.
Rikal jsem si ze bych uz do vyvoje nerad zasahoval protoze to nevyvijim a nechci nikomu kecat do jeho prace, ale rad bych apeloval na implementatory: zpravy jsou sice hezka vec, ale neexistuje duvod (a nikdy neexistoval) proc je implementovat. Existuji a jsou preci provozovgany mnohem ucinnejsi formy komunikacnich kanalu ktere snad v kazdem cloudu behaji. Zpravy zbytecne komplikuji aplikaci, pridavaji ji funkce ktere jsou zbytecne a duplicitni.
Zakladem projektu bylo vytvoreni systemu siriciho informace o zdrojich czf, veskere dalsi funkce jsou sice mozna hezke featurky, ale jsou nadbytecne.
12.07.2005 v 16:33
