Mail-Framework (was: Re: [linux-l] Wohin mit den alten Mails? -> +sent)

olafBuddenhagen at gmx.net olafBuddenhagen at gmx.net
Do Feb 15 09:51:12 CET 2007


Hallo,

On Tue, Feb 13, 2007 at 01:48:37PM +0100, Oliver Bandel wrote:

> Schade, das die meisten Progrämmchen nicht modularisert daher kommen
> und zusammen gestöpselt werden können, so daß man
> smtp-/imap-/pop-nntp/-http-Krams fertig da liegen hat und quasi von
> Hand bedienen kann (a la nget oder wget) und man dann oben drauf was
> drauf flanschen kann, was die GUI angeht.

Eben eben...

> Oder statt executables halt ne API, an die man sich einfach dran
> flanschen kann.
> 
> Also sowas wie eine eher Bibliotheks-basierte Version, statt zig
> verschiedene Programme, alle mit eh dem selben Krams neu
> implementiert.

Ich plädiere natürlich für eine Dateisystem-Schnittstelle :-)

> (Das hat aber auch einen Vorteil: wenn die Lib, die man benutzen
> würde, exploitbar ist, wären auf einen Schlag alle Programme von
> Sicherheitslücken betroffen.)

Das ist einer der Nachteile von gelinkten Bibliotheken, und auch der
Grund, wieso sichere Systeme (sowas wie EROS) keine Shared Libraries
benutzten, sondern stattdessen Funktionsblöcke in extra Serverprozesse
auslagern, und über RPCs ansprechen.

Bei Hurd sind Dateizugriffe übrigens auch nur RPCs an den Server-Prozess
(Translator), der den jeweiligen Teil des Dateisystems implementiert.
Eine Dateisystem-Schnittstelle ist unter Hurd also einfach nur eine
RPC-Schnittstelle, die sich an eine bestimmte Semantik hält.

> Eine Wunschliste mit Beschreibung der Tags-Sachen und Such-Mechanismen
> wäre ganz sinnvoll. Dann könnt' man sich ja was ausdenken, wie man
> sowas löst.

Stimmt. Klingt aber verdächtig nach Arbeit... ;-)

Im Ernst, Ideen für Andere verständlich aufzuschreiben, ist extrem
schwer -- für mich zumindest :-(

> Vor zwei Jahren habe ich mir mal eine mbox-Lib geschrieben. Bisher
> habe ich die aber nie mal irgendwie ernsthaft gebraucht. Wäre aber
> machbar, das mal zu reaktivieren und ggf. auf andere Ablageverfahren
> für Mails zu erweitern.

Hm... Sehe nicht so ganz, wie das dabei helfen könnte, die entsprechende
Funktionalität in Mutt zu implementieren? Oder bezieht sich das eher auf
den oberen Teil, eine universell verwendbare Mail-Komponente zu
schreiben? Könnte man natürlich auch versuchen, aber klassische
UNIX-Mechanismen sind für sowas IMHO schlecht geeignet. So ein Framework
(nicht nur für Mailzugriff, sondern generell für besser modularisierte
Anwendungen) schwebt mir seit Längerem vor, aber ich sehe Hurd hier als
Plattform der Wahl...

-Olaf-



Mehr Informationen über die Mailingliste linux-l