[linux-l] mutt und header caching (was: Wohin mit den alten Mails? datenbank? dbm?)

[Rocco Rutte]

Hi,

* Oliver Bandel [07-03-20 16:00:41 +0100] wrote:

>> Das hängt davon ab. Eigentlich werden die gängigen DB-Manager (gdbm, 
>> qdbm, Berkeley DB) unterstützt und genutzt, um Key-Value-Paare zu 
>> speichern. Die Binärdatei ist die "Datenbank".

>OK, also doch der gleiche Ansatz mit berkeley-db. :)

Nur wenn weder qdbm noch gdbm da sind. Das ist nur der Notnagel und dem 
Code nach zu urteilen glaube ich sofort, dass Berkeley-DB suboptimal ist 
und mann es nicht verwenden will. :)

>> >Was steht da drin? Wie ist der Aufbau?

>> Da wird als Key nur "Folder/Message-ID" benutzt, wobei Message-ID nicht 
>> die aus dem Header ist sondern je nach Folder was anderes ist. Nummern 
>> kriegt man via IMAP, einen Hexstring von POP, der Teil des Dateinamens 
>> in Maildir ohne Flags oder die Sequenznummer bei MH. Also irgendwas, was 
>> die Nachricht pro Odner eindeutig identifiziert. Ordner davor und es ist 
>> eineindeutig.

>Das heisst, das ist die Tabelle, die für z.B. Thread-Darstellung genutzt wird.

Jein. Das ist wirklich nur der rohe Header der Mail mit den References, 
der Message-ID, Subject, Anzahl Zeilen etc. Threading ist Darstellung 
und wird daraufhin immer neu berechnet. Erstens muss das so sein, weil 
man wegen dem Bug nur einmal schreiben kann (d.h. sie wird exakt dann 
geschrieben, wenn sie geladen wurde, also ohne Threading etc.) und 
zweitens, weil man mutt unterschiedlich einstellen kann und eine 
Speicherung dieser Daten wenig Sinn macht.

Es gibt aber, so nebenbei :), auch Überlegungen, da mehr Infos mit 
Checksumen drin zu speichern, die zur Laufzeit sehr teuer sind. Zum 
Beispiel kann mutt Anhänge zählen, in Abhängigkeit davon, welcher 
Content-Type für den User ein Anhang ist (ein PNG ist einer, eine 
gpg-Signature nicht, o.ä.). Für sowas muss man die Mail komplett 
MIME-parsen, was man bei unveränderten Einstellung sinnvollerweise aus 
dem Cache holt, gerade bei Remoteprotokollen wie POP und IMAP (aber 
dafür hilft da $message_cachedir viel weiter)... aber ich schweife ab... 
*g*

>Man könnte ja auch noch eine für Keywords/Tags nehmen und dann auf die
>jeweilige Message-ID verweisen.
>Ich hatte mal überlegt, ob eine DB alle Keyowrds bekommen soll, oder
>ob amn aus irgend einem grunde pro Keyword eine DB nimmt.
>Ist aber damals wegen Ablenkungen der dritten Art nicht mehr weiter
>verfolgt worden.

Da bräuchte man noch eine Tabelle, die sagt welche Tabellen es für 
welche Keywords gibt. Wenn man da nur exakte Suchen zulässt 
(insbesondere keine regex), wäre das sogar wahrscheinlich sehr 
performant. Aber regex will man ja haben also iteriert man wieder über 
alle Keys und sucht nach Matches.

Bei mutt gab es auch ansatzweise Diskussionen über X-Label, ein UI für 
die Eingabe und so weiter. Aber scheinbar gibt es da zu wenig Interesse.

>Aber jedenfalls schon mal interessant, daß mutt da auch Berkeley-DB nimmt.
>Naja, warum auch nicht, ist es ja eh installiert.

Wenn man große Ordner hat, die man mehr oder weniger nicht ständig neu 
cachen lassen will: qdbm oder gdbm, kein bdb.

>> Als Value werden im Prinzip die mutt-Strukturen via memcpy() und einem 
>> put() (ganz grob) benutzt. D.h. beim Laden hat man schon alles in den 
>> Strukturen und muss nicht noch groß zusammenbauen sondern nur ein paar 
>> Pointer zuweisen.

>Aha.
>Krass. Und in den Strukturen steht dann eine File-Position?
>An letztere hätte ich nämlich als erstes gedacht.
>Die müssen doch aber auch erst mal eingelesen werden.

Äh, nein. mutt cached nur für POP, IMAP, Maildir und MH, d.h. kein mbox.  
Für mbox macht es auch wenig Sinn, weil a) mutt die mailbox so sortiert 
ablegt wie es das für sinnvoll hält (um nicht ständig zu seek()en für 
die Anzeige) und b) jedes andere Mailtool das wieder umstortieren 
könnte. D.h. man müsste bei jedem Cachezugriff noch gucken, ob die 
Message wirklich noch an der gleichen Stelle ist. Wenn jetzt jemand am 
Anfang eine Mail einfügt (was technisch legitim ist), dann ist der 
komplette Cache sinnlos. Oder die Mail hat keine weiteren Flags und der 
MUA fügt jetzt ein Flag ein -> wieder andere Offsets -> Cache ungültig.

Bei File-/Message-basierten Ordern wie die obigen 4 sieht es da schon 
anders aus. Die IDs sind mehr oder weniger garantiert stabil und eine 
Existenzprüfung ist trivial: stat() für lokale Ordner zum Beispiel.

Sicher, man könnte für mbox (und mmdf) daran noch rumoptimieren, aber es 
bringt nicht viel. Außerdem ist erfahrungsgemäß bei mutt mbox nicht 
wirklich langsamer beim Öffnen als maildir/mh (an anderen Stellen schon, 
bzw. hat andere krasse Nachteile), d.h. es würde auch nicht viel bringen 
mbox noch zu cachen. Eventuell nur, um die Locking-Zeitspannen zu 
drücken, aber wahrscheinlich nicht mal das, weil mutt eh tempfiles 
schreibt und die dann als Block (genau deswegen vielleicht?) committet.

   bye, Rocco
-- 
:wq!