[linux-l] Re: Wohin mit den alten Mails? datenbank?

Oliver Bandel oliver at first.in-berlin.de
Di Mär 27 03:01:59 CEST 2007


On Mon, Mar 26, 2007 at 06:03:05PM +0200, olafBuddenhagen at gmx.net wrote:
> Hallo,
> 
> On Mon, Mar 26, 2007 at 01:10:06AM +0200, Oliver Bandel wrote:
> > On Thu, Mar 22, 2007 at 07:23:55PM +0100, olafBuddenhagen at gmx.net
> > wrote:
> 
> > > Meine Situation ist eine ziemlich riesige Mailbox (>500 MiB, ca.
> > > 60000 Mails), geöffnet über (schlecht implementiertes) NFS -- das
> > > Einlesen dauert in Mutt etwa zehn Minuten. Ich frage mich ob Maildir
> > > mit Header-Caching hier Abhilfe schaffen könnte.
> > 
> > Probier es doch mitkleineren mbox-Files. Einmal proKalenderjahr ein
> > neues anfangen, das könnte schon helfen ;-)
> 
> Vergiss es.
> 
> Weißt Du überhaupt noch, worum es in diesem Thread eigentlich ging?...
> Der Ausgangspunkt war gerade, dass ich *nicht* in verschiedene Ordner
> aufteilen will.


Doch, das wusste ich noch, aber ich fragte keckerweise trotzdem nochmal. :)

Und warum willst Du nicht mehrere mbox-Files haben?

Doch nur, weil mutt es dann nicht verwalten kann,
Du aber mutt wegen seiner sonstigen Funktionalität hoch schätzt,
oder?!



> 
> > > Ich denke die einzig wirklich elegante Lösung wäre, das sozusagen
> > > objektorientiert anzugehen: Gar kein direkter Zugriff auf die
> > > Maildateien durch die Tools, sondern nur über einen Daemon, an den
> > > sich alle Programme wenden müssen. Keine Locking-Probleme mehr, und
> > > man hätte beliebig Flexibilität, wie die Daten auf der Platte
> > > abgelegt werden, ohne große Kompatibilitätsprobleme.
> > 
> > Was ist denn hier das elegante/effiziente? OO oder Daemon? Oder
> > beides? Und: was meinst Du mit OO in dem Zusammenhang? Und: was soll
> > durch Dein anderes Konzept verbessert werden? Wo wird der Zugriff
> > effizienter? Was genau willst Du da den Daemon machen lassen?
> 
> Objektorientiert in dem Sinne, dass nicht alle möglichen Anwendungen
> direkt in den Mailbox-Dateien herumstochern, sondern die Daten in einem
> Objekt gekapselt sind (implementiert von einem Daemon), und der Zugriff
> durch Methoden erfolgt.
> 

Wenn es keinen Unterschied für Dich macht, ob Du es
Methoden oder Kommandos nennst, dann geht doch IMAP wohl.

Wie es allerdings dann mit der Suchfunktionalität aussieht?
mutt kann auch pop und imap verstehen.
Da ich allerdings die etwas abgehobeneren Suchfeatures bei meinem
mutt noch nicht ausprobiert hatte, weiss ich auch nicht,
ob die alle auch über die Netzwerkstrippe zugänglich sind,
oder nur, wenn man auf die Zylinder direkt zugreift.

Mein mutt zeigt mir via imap (imaps) nicht die Größe der Dateien
an, bevor man sie nicht runtergeladen hat.
Besonders, wenn man dann MB-große File bekommt, die man nicht erwartet,
und womöglich noch ein Modem dran hat... (gut, daß ich seit einiger
zeit auch DSL habe... das war nervig, wenn man nicht weiss,
welche Mail so groß ist. Und besonders, wenn der Unsinn dann womöglich Spam
ist.)


> Hauptvorteil wäre, dass man nicht mehr an eine bestimmte physische
> Struktur für die Mailbox gebunden ist, da Programme nicht mehr direkt
> darauf zugreifen. Der Daemon könnte die Daten ablegen wie er lustig ist,
> von mir aus in einer Datenbank -- die Schnittstelle nach Außen ist davon
> unbeeinflusst.

Ja. Er könnte sogar mbox benutzen, wenn er wollte :-)

Also wäre es hinreichend, eine Abstraktion beim Zugriff zu schaffen,
statt auf mbox zu beharren.

Und was, wenn der Daemon viele, viele kleine mböxchen statt einer ganz
großen nutzt?
Würdest Du das immernoch als inakzeptabel ansehen? ;-)

Das Problem ist also dann garnicht (mehr)
 "mbox muss es sein und eine einzige soll es sein".

Sondern das Problem ist "wie kriege ich Zugriff auf alle Mails
 der letzten dreitausend Jahre, unter Beibehaltung von mutt's
 Suchmöglichkeiten".


> 
> Nebenbei wäre es ziemlich einfach, Konsistenz zu sichern, da alle
> Zugriffe über den Daemon erfolgen; man bräuchte keine umständlichen und
> unzuverlässigen Locking-Mechanismen mehr.

Und wenn der Daemon mehrere Anfragen quasi-parallel bearbeiten kann?
Dann macht er das nur, wenn er sauber implementiert ist und gleichzitige
Zugriffe verwaltet.
Wenn er immer nur einen Zugriff bearbeitet, also ein serieller Server,
dann kann janichts passiern, aber es kann auch länger dauern, bis alle
Leute ihre Anfragen durch haben (oder man selbst kann auch keine
zweite abschicken).



> 
> > Willst Du IMAP reimplementieren?
> 
> An IMAP habe ich garnicht gedacht. Vielleicht ist das ja tatsächlich
> eine Lösung. Wie werden die Mailboxen denn bei IMAP verwaltet?

Keine Ahnung. Musst Du wohl der jeweiligen Implementierung überlassen.
Wolltest Du das nicht auch?! :)

Aber es gibt da jedenfalls ein SEARCH-Kommando im IMAP-Protokoll.
Also sollte das alles machbar sein.


> Ist es
> so, dass nur der IMAP-Server direkten Zugriff darauf hat, und der MDA
> beim Einliefern neuer Mails sich an den IMAP-Server wendet?

Ja, der IMAP-Server verwaltet die Mails und man wendet sich an den
Server und sagt ihm, was man haben will.


> 
> Nachteil von IMAP wäre der Overhead durch das Netzwerkprotokoll -- mir
> geht es hier ausschließlich um das lokale Ablegen von Mails.

Dann müsstest Du das Teil wohl lokal einrichten.
Wie irgendwelche imapd's das nun machen, ob die
mbox oder Datenbank oder sonstewas nutzen, weiss ich nicht;
wird wohl abhängig sein von der jeweiligen Implementierung.
Oder vielleicht sind die Teile auch flexibel genug und
können auf unterschiedliche Mailablage-Ressourcen zugreifen.



> Ich finde
> generell, dass es sinnvoller ist, zunächst eine rein lokale Lösung zu
> haben, und Netzwerkprotokolle optional darüber zu legen, als von
> Vornherein alles über Netzwerkprotokolle zu machen. (Den Ansatz von X
> finde ich zum Beispiel ziemlich blöd.)

Naja, das gleich auf Netzwerebene abzuhandeln bietet
den Vorteil der Flexibilität. Man braucht nur ne
andere IP und fertig ist's.
Deswegen finde ich den Ansatz von X ganz gut. :)
Ist ja schliesslich extra dafür da, um über's Netz
zu arbeiten. Man kann das *auch+ lokal machen,
aber eben auch remote.
Hingegen muß man bei lokalen Sachen dann so Umwege
wie NFS sich ans Bein binden. Und selbiges hat sich bei
mir als unzuverlässig eingeprägt.


> 
> > > (Um Kompatibilität zu bestehenden Programmen zu wahren, könnte man
> > > über FUSE unter Linux, Translator unter Hurd, oder ähnliche
> > > Mechanismen klassisches mbox und/oder Maildir emulieren.)
> > 
> > OO -> Adaptor?
> 
> Keine Ahnung was das ist :-)
> 

Das ist sozusagen das Teil, mit dem man von Bananenstecker (usw.) auf
BNC-Stecker geht (oder SMC oder Klinke oder andere).

Ein Adapter eben. Bloß, daß der in Software realisiert ist.

Eine Schnittstellenumsetzung von A nach B könnte man auch sagen.


Gruß,
   Oliver

-- 
http://me.in-berlin.de/~first/



Mehr Informationen über die Mailingliste linux-l