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

[olafBuddenhagen at gmx.net]

Hallo,

On Tue, Mar 27, 2007 at 03:01:59AM +0200, Oliver Bandel wrote:
> On Mon, Mar 26, 2007 at 06:03:05PM +0200, olafBuddenhagen at gmx.net
> wrote:

> 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?!

Nicht ganz. Der Punkt ist, dass ich direkten Zugriff auf *alle* Mails
möchte, ohne durch verschiedene Ordner wechseln zu müssen. Selbst wenn
mutt die Fähigkeit hätte, mehrere Ordner zusammenzufassen, müsste es die
immer alle einlesen -- viel gewonnen wäre damit nicht.

> Mein mutt zeigt mir via imap (imaps) nicht die Größe der Dateien an,
> bevor man sie nicht runtergeladen hat.

Stimmt, sowas habe ich glaub' ich auch gesehen im Büro, wo ich IMAP
benutzt habe... Das allein ist ein k.o.-Kriterium.

Solche Probleme ergeben sich nur, weil IMAP eben nicht wirklich für
diese Anwendung gemacht ist. Es ist ein kompliziertes Protokoll, um
halbwegs effizient über eine langsame Verbindung arbeiten zu können. Das
will ich alles nicht. Ich möchte einfach nur einen Daemon, der das
eigentliche Lesen und Schreiben der Mails erledigt; jegliche
Verarbeitung sollte Client-seitig erfolgen, wie bei 'ner ganz normalen
lokalen Mailbox.

> > 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?

Brauche ich nicht wirklich; ein globaler Write-Lock würde mir völlig
ausreichen... So wie es bei klassischer mbox ja im Prinzip auch der Fall
ist -- nur dass der Lock wesentlich einfacher und robuster von einem
Prozess verwaltet werden kann, als über File-Locking.

> > 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. :)

Ich finde das gerade inflexibel. Man ist an ein bestimmtes
Netzwerkprotokoll gebunden. Wenn man spezielle Anforderungen hat,
braucht es irgendwelcher Protokollerweiterungen oder suboptimaler
Workarounds etc.

Viel flexibler ist man, wenn man beliebig wählen kann, wie man die
Sachen über's Netzwerk schiebt -- ssh, NFS, 9p, WebDAV, NNTP, ...

> Hingegen muß man bei lokalen Sachen dann so Umwege wie NFS sich ans
> Bein binden.

Das ist kein Umweg. Das ist nur saubere Trennung. UNIX-Prinzip, schon
mal gehört? :-)

Das macht die Programme wesentlich flexibler, und gleichzeitig viel
einfacher.

Ich finde Plan9 macht das richtig.

> Und selbiges hat sich bei mir als unzuverlässig eingeprägt.

Neuere NFS-Versionen sollen wohl generell besser sein. Allerdings ist
NFS nicht wirklich für andere Anwendungen als exportieren echter
Dateisysteme gedacht; zum Remote-Zugriff auf andere Resourcen wohl eher
ungeeignet. Ich vermute 9p ist da brauchbarer...

-Olaf-