On Wed, 2003-07-30 at 08:50, Radu Filip wrote: > 4) Comentarii. Comentariile sunt de foarte mare ajutor si mai mult, se > alfa localizate nu in nu stiu ce fisiere de help cu chiar impreuna cu > "cheia" in sine, exact in locul cel mai potrivit: in fisierul de > configurare > 5) Alt motiv ar fi intuivitatea: este mult mai simplu sa iti amintesti sau > sa deduci cam pe unde se afla un fisier de configurare, decat sa tii minte > exact cheia din registry. Stii ca fisierele de configurare se afla prin > /etc, cauti un fisier care incepe cu numele aplicatiei care nu porneste, > si apoi citind si comentariile din el, poti deduce ce nu ar merge. Ce este > intuitiv aici: HKLM\Software\CLASSES\exefile\shell\open\command -> > "default REG_SZ \"%1\" %* "?
Ok, am sters mult din mesajul tau (si-o sa mai sterg :-D) dar in esenta am aceeasi observatie de facut peste tot: se pare ca nu critici ideea generala de registry (configurare centralizata) ci o anume implementare particulara, plus ca oscilezi intre critica backend-ului si critica frontend-ului aparent fara o delimitare clara (unul apare ca fiind "rau" din cauza celuilalt). Nici mie nu prea-mi place implementarea Microsoft. Dar salivez zilnic dupa ideea de configurare centralizata in Unix. > 7) Poti cauta in anumite/toate fisierele de configurare cu grep, care este > o unealta de cautare _mult_ mai puternica decat rudimentarul find. Fie si > numai pentru ca grep suporta, asa cum ii spune si numele, expresii > regulate Right. Asta din cauza ca _implementarea_Microsoft_ nu suporta grep pe registry, nu din cauza ca ar exista vreo incompatibilitate fundamentala intre registry si grep. Kernel-ul Linux e mult mai complex ca registry-ul Windows, si totusi poti face grep peste o gramada de structuri importante din el, in mod dinamic, in timp ce ruleaza. Stii la ce ma refer, nu? ;-) (bineinteles ca stii, e doar o intorsatura retorica) > 9) SPOF. Single point of failure. A gresi e omeneste si e mult mai usor sa > gresesti stergand intreg registry-ul, decat stergand o multime de fisiere > de configurare. Configurare centralizata != stocarea datelor intr-un singur loc Vezi mesajul meu precedent. > 10) Majoritatea admnilor prefera modul text pentru administrare (vorbim > aici inclusiv de cel mai eficient mod de remote admin: ssh), si este mult > mai simplu sa folosesti un editor text decat o aplicatie text-mode cu > tree-view, etc). Ai vazut cum e pe FreeBSD cu baza de date de parole? Nu e text, dar interfata catre ea (vipw) e "text-like" (te face sa juri ca e text). Ok, simplific situatia in mod grosolan, si mint un pic, si sint constient de criticile care se pot aduce la ce am zis, dar intelegi ce vreau sa zic. > Si in final, inca un argument. Dupa atatia ani de fisiere binare, formatul > pentru schimbul de date care se impune este XML, care este text-based. > Tocmai datorita faptului ca oamenilor le va veni intotdeauna mai usor sa > "parseze" vizual text decat sa fie dependenti de nu stiu ce utilitare > obscure pentru a intelege formatul unor date. Ok, deci am visat si eu treaz in directia asta, un pic. Iar XML a fost p-acolo pe undeva, prin peisajul oniric. Sint de acord cu tine in privinta avantajelor XML. Dar ce zici de ideea asta: sa ai, daca nu un API propriu-zis, macar o modalitate standard de accesare a setarilor. Stocarea sa se faca "imprastiat" (nu totul intr-un singur loc), pe baza de XML sau ceva similar. Peste API-ul ala or whatever, construiesti unelte text-mode pentru cui ii place text, GUI pentru cui ii place GUI, etc. Fiind XML, extensibilitatea e practic infinita (cel putin in anume directii). E in esenta text-based, deci poti sari peste API daca situatia o cere (anumite urgente, sistemul a crapat de n-a mai ramas decit root discul...). Plus ca e usor de construit biblioteci de tot felul peste backend-ul XML. Toate aplicatiile acceseaza treaba asta printr-o biblioteca dedicata, numita libconfig sau ceva de genul asta (heck, o poti colapsa in glibc la o adica, pentru ca e ceva fundamental). Intr-un anume sens, si softurile stil DJ Bernstein incearca sa faca ceva vag similar. Cauta sa defineasca reguli clare, dar flexibile, de stocare a setarilor: Back-end-ul e sistemul de fisiere. Unitatea de stocare e fisierul. Nu se stocheaza mai mult de o variabila intr-un fisier. Structura setarilor e data de structura de directoare. Wunderschon! :-) Sint de acord, schema asta are destule lipsuri comparata cu XML, asa cum are si unele avantaje (are toate avantajele care decurg direct din design-ul spartan, si toate dezavantajele). Ca sa fiu sincer, mie situatia actuala cu configurarile in Unix mi se pare ridicola, si ma mir neincetat cum de nu realizeaza toti chestia asta. :-) Fiecare soft cu stilul lui de setari, imprastiate care pe unde apuca, etc. Daca as lista doar motivele pentru care asta e rau, as mai scrie inca o data pe cit am scris pina acum. :-) D-aia ziceam ca visez la un Registry pentru Unix, dar implementat cum trebuie. Deci, ai un backend, care poate fi o colectie de fisiere XML imprastiate prin /etc, sau poate fi altceva (niste aluzii la distributed computing ar putea face discutia un pic mai "picanta", dar sa ne limitam la ce s-a spus pina acum). Peste ala ai o biblioteca, care e dispecerul de acces la backend, rezolvind chestiile de acces concurent, implementind chiar un soi rudimentar de tranzactii, etc. La nivelul asta se poate face replicare (whatever that means) ca sa eviti a distruge toate setarile dintr-un foc; daca le-ai ras, folosesti un restore, ceva, si le aduci inapoi (asa ceva nu se poate face cu setarile clasice text, cel putin nu de la sine, ci trebuie sa muncesti tu pentru asta, cu backup-uri, etc.). Peste lib ai o ciurda de frontend-uri, fiecare cum il taie capul, plus aplicatiile in sine. Din cauza stratului intermediar care face "traducerea" (biblioteca), poti optimiza backend-ul conform criteriilor valabile la backend-uri, poti optimiza frontend-urile cf. criteriilor valabile la frontend-uri, etc. Nu ca la Windows, unde frontend-ul se indoaie si se strimba din toate alea ca sa urmareasca un backend abstract si lipsit de sens la nivel ridicat, nici ca la Unix unde situatia e inversa (dupa cum vezi, fac un compliment interfetei text). I can dream... -- Florin Andrei I updated my website: http://florin.myip.org/
