On 01 Sep 2001 02:06:54 +0300, Petru Paler wrote:
>
> Which reminds me ca tot vreau de mult sa incerc o migrare spre Evolution:
>
> 1. Care versiune e recomandabila (cel mai usor mi-e sa folosesc beta2 ca
> ala e in debian unstable)?
Eu folosesc beta2.
Inainte de beta, cel mai bine era sa folosesti release-urile, si sa nu
te prea atingi de devel-uri. Acum nu mai stiu cum e. Din inertie, tot cu
release-urile ma tzin... :-)
> 2. Care e stadiul shortcuturilor pe tastatura? Poti face marea majoritate
> a operatiilor din taste?
Habar n-am. /me = MMU (moronic mouse user) :-P
Incearca si tu.
> 3. Cum e suportul PGP/GPG?
Nu am facut decit teste superficiale, dar se pare ca merge daca ai
pgp-ul instalat. Mi-a criptat corect mesajele, le-a semnat, a fost
capabil sa decripteze propriile mele mesaje, etc.
> Da. Ciudat, nu m-am gandit niciodata la Cyrus ca "imbunatatire la maildir",
> ci ca la un format separat :)
Ok, urmeaza un simplu sir de presupuneri, daca zic prostii nu dati cu
oua stricate.
Ai vazut ca Hans Reiser, in afara de faptul ca e un avocat exceptional
pentru propriul produs (si face singur cit zece agentii de publicitate,
ca-ti vine sa-i pui leucoplast la gura), e foarte excitat de chestia cu
plug-in-urile in ReiserFS. L-am auzit, de mai multe ori, comitzind faze
de genul "sa extindem semantica FS-urilor", etc. Destul de revolutionar
baiatul... ;-)
In acest spirit, si pornind de la analogia frapanta care este intre ce
face Cyrus si ce face un FS adevarat, ma gindesc daca ar avea sens sa se
investigheze care ar fi elementele specifice functionarii unui inbox, sa
se identifice operatiile fundamentale, si sa se "extinda semantica unui
FS" (TM: Hans Reiser) cu chestiile astea. De exemplu, sub forma unui
plug-in RFS.
Cum ar veni, lasi sa se ocupe kernel-ul de chestiile cu metadate, etc.
pe care acuma le face un program userspace - Cyrus. Adica, nici o
diferenta in afara de faptul ca metadatele sint stocate la nivel de FS,
nu la nivel de fisier (daca tot sint meta-date, de ce sa nu le stochezi
acolo unde le e locul - in FS?) si in felul asta elimini un nivel de
prelucrare a informatiei care nu face decit sa consume cicli CPU
degeaba.
Deci, definesti o extensie la API-ul de lucru cu fisiere, specifica
pentru operatiile cu inbox-uri, si toate operatiile cu discul facute de
MTA/MUA sint superoptimizate. Daca scrii un nou MTA/MUA, nu mai trebuie
sa te ingrijesti de formatul inbox-ului, pentru ca cu asta se ocupa
kernel-ul.
Daca nu esti MTA/MUA si nu folosesti API-ul ala, vezi mesajele ca
fisiere chioare, si ai acces neoptimizat la ele (eventual doar
read-only, ca sa nu bulesti consistenta?).
Ok, sau, ca sa nu extinzi API-ul (lucru care nu prea e pe placul
multora), definesti accesul la metadate prin fisiere speciale (cam cum e
/proc) si nu mai trebuie sa introduci functii noi, ci controlezi totul
din functii-fisier clasice (metadatele fiind in fisiere speciale). Ar
trebui sa fie cam tot aia...
Pe de o parte, poate nu merita sa impingi atita cod in kernel pentru un
task atit de specializat.
Pe de alta, tot vrea Hans sa faca RFS-ul baza de date. :-)
Oare merita sau nu?
--
Florin Andrei
---
Send e-mail to '[EMAIL PROTECTED]' with 'unsubscribe rlug' to
unsubscribe from this list.
