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

[Oliver Bandel]

Moin,

On Thu, Feb 15, 2007 at 08:56:56AM +0100, olafBuddenhagen at gmx.net wrote:
> Hallo,
> 
> On Tue, Feb 13, 2007 at 02:21:19PM +0100, Oliver Bandel wrote:
> 
> > > Interessanter wird es, wenn zum beispiel auf der BeLUG-Listen eine
> > > SWPat-Diskussion aufkommt. Dann hat sie schon automatisch das
> > > BeLUG-Tag, aber ich kann ihr dann manuell auch noch das SWPat-Tag
> > > vergeben, so dass sie auch neben den Mails von den FFII-Listen
> > > erscheint. Sehr praktisch.
> > 
> > Man könnte auch nach Worten einen Index aufbauen und alle Mails
> > automatisch auf Keywords checken. Sind Keywords gefunden worden, kann
> > man dadraus einen entsprechenden Tag generieren
> 
> Bin nicht sicher was Du genau meinst. Willst Du nach festen
> Schlüsselwörtern Tags vergeben?

Das kann man doch anbieten; ob es automatisch gemacjt werden sollte,
hmhh, nun, dabin ich mir nicht ganz sicher; ich denke, das sollte
man demjenigen Überlassen, dem die Maisl zugesandt werden.
Schliesslich können Keywords auch auftauchen, wenn es sinngemäß nicht ganz passt.

Aber  man *könnte* das dahingehend zumindest automatieieren.
Das heisst ja nicht, man *sollte* es auch so machen.


> Das scheint mir erstens sehr
> unzuverlässig, und zweitens sehe ich dabei keinen Vorteil gegenüber der
> Eingabe von Schlüsselwörtern erst bei der eigentlichen Suche...

Eingabe von Schlüsselwörtern bei der Suche?
Du meinst also eine Volltextsuche?

Naja, je nach Datenbestand, oder ob de Originaldaten vorliegen oder nicht,
ist das  ja nicht unbedingt möglich.

Keywords, vorher raus gepickt, sind wie ein Inhaltseverzeichnis.
Das kann man sich separat legen.
hat man es nicht, muß man den gesamten Datenbestand absuchen.

Man muss wohl auch unterscheiden zwischen Suchen, wo man sowieso
immer bestimmte Sachen suchen wird, und Suchen, wo man nach Sachen sucht,
nach denen man bisher niemals suchte.
Für Letzteres ist Tag-Search schon mal ungeeignet, Keywords je nach
Suchkatagloig auch oder sind möglicherweise noch nutzbar.

Kommt eben drauf an, was man meint, in welcher Weise man wie und was recherchierenw
zu gedenkt.


> 
> Was man hingegen machen könnte, wäre über Textähnlichkeitsanalyse (Bayes
> oder so) automatisch Tags zu vergeben, statt oder ergänzend zu den
> festen Regeln.


Bayes ist zwar wohl ganz nett, aber eigentlich "veraltet".
Schon seit (mindestens) Ende des letzten Jahrtausends, wenn man es genau nimmt.
Das sind ja auch schon 8 bis 10 Jahre.

Und so lange schon rede ich gegen Wände.
Aber was solls.



> 
> (Tatsächlich ist einer der Gründe, wieso ich mich bisher zu keiner
> Mailsortierung überwinden konnte, dass ich zu faul bin manuell Regeln
> festzulegen...

Hahah, das kenne ich.
Deswegen habe ich weder Indzierung noch Tags....
...und für manche Backups war wohl die
Auto-Feng-Shui-Option angeschaltet, also: nach ende
des Merkbarkeitsdstums bitte automatisch vernichten.
Oder war es Bermuda-Dreiecks-Option=On ?!



> Allerdings sind praktisch alle verbreiteten
> Bayes-Lösungen nur für eine stupide Spam-oder-nicht Klassifizierung
> ausgelegt -- für automatische Sortierung in mehrere Kategorien gibt's
> kaum was :-( )

Bayes => /dev/null


> 
> > Das ganze Problem, das man hier hat ist eines, für das man ja wohl
> > Datnbanken entworfen hat. Für sehr große Datenbestände mag es evtl.
> > sinnvoller sein, einen mbox2sql zu schreiben und man füttert das dann
> > alles in ein RDBMS ein
> 
> Habe ich auch schon überlegt. Allerdings haben "echte" SQL-Datenbanken
> den erheblichen Nachteil, dass die Daten darin sehr viel schwieriger
> zugänglich sind als Daten, die direkt in einfachen Text-Dateien (mbox)
> und/oder Dateisystem-Strukturen (maildir) abgelegt sind.

Ja, stimmt schon.... grep ist ja immernoch eins meiner Libelingstools. :)

Andererseits, wenn man sowieso weiss, wonach man sucht,
also seine Recherche-Keywords sowieso kennt, was spricht
gegen Indizierung?
Und man kann Indizes ggf. auch erneut über die Daten laufen lassen,
man muss es aber nicht. Das heisst: hat man sie, ist es OK, hat man sie nicht,
arbeitet man eben ohne welche. Aber warum drauf verzichten?
Man kann Volltextsuche mit dem mutt ja machen, aber zusätzlich eben
noch Indizieren.

man kann auch grep auf alle mbox-Files anwenden, grep -n
und dann     vi + <zeilennummer>.

So gesehen braucht man auch keinen mutt für sowas.

Viele Wege...


(...it depends on...)


> 
> Unter Hurd könne man das zwar abmildern, indem man mit einem Translator
> die Daten transparent als Verzeichnisstruktur darstellt,

Was meinst Du?
Was soll dieser Translator sein?


> obwohl sie
> intern in einer SQL-Datenbank ablegt sind. (Mit neueren Linux-Versionen
> könnte das dank FUSE vielleicht auch gehen; weiß nicht wie gut das für
> sowas geeignet ist...)

FUSE?

Fuse?

Brennt mir nun doch noch die Sicherung durch, oder was meinst Du?



> 
> Besser wäre es aber, wenn das eigentliche Dateisystem von sich aus mit
> komplexen Verzeichnisstrukturen effizienter umgehen könnte. Ich denke
> der Weg mit maildir ist prinzipiell schon richtig; ist nur eben sehr
> ineffizient bei klassischen Dateisystemen :-(

Naja, was soll Maildir im Vergleich zur mbox denn bezüglich Recherche
verbessern?
Ob man über Einträge im Dir oder Positions im mbox-File iteriert
ist doch letztlich egal, wenn man es vergleicht mit einer
Suche, die auf Keywords/Tags basiert (statt Volltextsuche im
gesamten Datenbestand).


> 
> > und macht dann irgendwas wie ein
> > 
> >  select body from mails where tag = 'Ubuntu";
> > 
> > oder sowas.
> > 
> > (Mag sein, das da oben im Beipiel entspricht nicht korrekter
> > SQL-Syntaxa aber ich mache ja SQL auch nicht jeden Tag. Aber sinngemäß
> > sowas da.)
> 
> Syntax ist korrekt, bis auf das offensichtlich falsche Anführgszeichen
> am Ende. Semantisch ist das aber trotzdem falsch: Damit hätte man nur
> ein Tag pro Mail, hätte also perfekt an der eigentlichen Zielstellung
> vorbeiimplementiert ;-)
[...]

Naja, ich sage ja: da gibt es Leute, die besser SQL können, als ich.


Gruß,
   Oliver