[linux-l] Wohin mit den alten Mails? -> +sent

[Volker Grabsch]

On Sun, Feb 11, 2007 at 04:57:31PM +0100, Olaf Radicke wrote:
> Du hast den Ansatz nicht verstanden. Vielleicht kann ich mich einfach 
> nicht ausdrücken.

Ich habe mehr verstanden, als du mir zutraust, aber in einem Punkt
habe ich dich tatsächlich missverstanden.

> Mutt kann auch mit maildir arbeiten. Aber Mutt oder Kmail interessiert 
> mich erst mal nicht. Ich arbeite mit einen externen Tool auf 
> Datei-Ebene. Also vergleiche ich die Struktur von mbox und maildir. Bei 
> Mbox habe ich eine Riesen-Datei. Wenn ich die öffne, muss ich irgend 
> wie sicherstellen, das kein anderes Programm das auch tut. Bei maildir 
> muss ich das nicht. Ich brauche die Dateien noch nicht mal öffnen.

Ja, schon klar, die Implementierung wäre bei Maildir leichter. Ist aber
nur ein dummes Implementierungs-Detail. Mit MBox-Format geht dein
Feature genauso zu realisieren, nur etwas aufwändiger.

Ein besonderes Zugriffs-Problem kann ich nicht erkennen, da du aus den
Mailboxen (egal ob Maildir oder mbox) erstmal nur liest bzw. Daten
hinten ran setzt. Es kracht also, wenn:

1) Mailprogramm und Tagging-Tool gleichzeitig in eine Tag-Mailbox
   schreiben
   -> unwahrscheinlich, da das Mailprogramm normalerweise nur aus
      den Tag-Mailboxen *liest*

2) Mailprogramm schreibt gerade dann eine Mail in die Mailbox, wenn
   das Tag-Tool sie liest
   -> Würde auch bei Maildir krachen

> Wenn mein Externes Tool ein Tag anlegt, ist bei Mutt auf einmal ein 
> neuer Ordner da.

Achso, du möchtest also das externe Tool nicht zum Anzeigen, sondern
zum Anlegen der Tags. Da hatte ich dich falsch verstanden.

> > Solche Details im Voraus festzulegen ohne echte Tests fände ich wenig
> > sinnvoll. Dann lieber eine API (z.B. Kommandozeileninterface oder
> > C-API) festlegen, und mehrere Implementierungen erlauben.
> 
> Die API ist so alt wie UNIX und heißt "Alles-ist-eine-Datei".

Dennoch gibt es so einige Details, die konfigurierbar sein sollten.
Außerdem sollte die Architektur sich IMHO nicht unnötig gegen mbox
sperren.

Aber egal, ob hartcodierter "mkdir .. ; ln -s .." oder Shell-Script:
Beides wäre gleichermaßen leicht in Mutt einpflegbar. Dann kannst
du das Zeug gleich im Mailprogramm taggen, was die Sache nochmal um
einiges benutzerfreundlicher machen dürfte.

> > Der einzige "echte" Unterschied zwischen deiner und Svens Strategie
> > ist AFAICS dass er die Tags in die Mails einfügt und die sie separat
> > haben willst. 
> 
> Nein. Sven sieht in Mutt eine "Entwicklungsumgebung" und ich halte mich 
> an die Devise "Ein Tool für genau eine Aufgabe". Der Mailer soll Mailen 
> und das Katalog-Tool soll katalogieseieren.

Ein Tool pro Aufgabe, aber nicht keine GUI pro Aufgabe. Außerdem sind
Bibliotheken ebenfalls "Tools", sie werden nur anders aufgerufen. Zum
Beispiel kann mutt sowohl POP als auch IMAP sprechen, und lokale
Mailboxen aufrufen .. sollte es dafür lieber 3 separate Programme geben?
Ist Mutt deswegen monolithisch? Nein, denn die extra Funktionalität
lagert sauber in extra Bibliotheken.

Eine Mail zu taggen finde ich genauso natürlich wie das Festlegen eines
Betreffs oder das Bearbeiten des Inhalts. An dieser Stelle könnte Mutt
auch einfach einen Tag-Parameter entgegen nehmen, und diesen direkt
verarbeiten oder ein eine Tagging-Bibliothek bzw.
Tagging-Kommandozeilentool weitergeben. Fände ich sehr viel flexibler.

Wenn's nicht einen Parameter verlangen würde (den Tagnamen), dann könnte
das Mutt sogar mit Boardmitteln ... ein einziger kleiner Eintrag in die
.muttrc wäre nötig.

Wenn das CLI-Tagging-Tool den Tagnamen sogar selbst an der Kommandozeile
abfragt, könnte es also sogar in Mutt integriert werden, *ohne* was am
Code ändern zu müssen.

Ich finde es sinnvoll, dass in einer GUI *mehrere* Kommandozeilentools
bzw. Bibliotheken *in Kombination* angesprochen werden. Das Mailen besteht
z.B. aus Editieren, Abholen, Senden, u.s.w.  Das Brennen einer CD
besteht aus mkisofs und cdrecord. Würdest du dafür zwei getrennte GUIs
verlangen, die sich gegenseitig die Daten zu-pipen können? Dann doch
lieber *eine* GUI, die *alle* Parameter auf einmal abfragt, und dann
die anderen Tools aufruft, um den Job zu erledigen.

Genau genommen ist eine GUI also auch nur ein weiteres Tool in diesem
Kombinieren der Tools. Und in der Tool-Kombination einer einzigen
Standard-Aufgabe (z.B. CD brennen oder Mails sichten) sollte nur eine
der Komponenten ne GUI sein.

(GUI ist hier etwas allgemeiner zu sehen. Ich meine damit sowohl
klassische GUIs als auch mutt als auch die interaktive Shell)


... obwohl ein System aus vielen kleinen GUIs auch seinen Reiz hat,
aber nur wenn die sich nahtlos integrieren (also wie eine große
konsistente GUI auftreten), oder wenn der Datenaustausch zwischen
ihnen problemlos geht. (Drag & Drop ist ein guter Ansatz, ohne Maus
sollte das aber auch möglich sein!)


Viele Grüße,

    Volker

-- 
Volker Grabsch
---<<(())>>---
Administrator
NotJustHosting GbR