[EMAIL PROTECTED] (Peter Moeckli) am 20.05.1999:
> > ...snip... Headerstripper...
> >
> > > Also, erstens braucht das nicht viel Platz, nur ein paar Bytes.
> >
> > Die "paar Bytes" machen in den von mir getesteten F�llen ca. das
> > doppelte des eigentlichen Nachrichteninhalts aus. Mit anderen Worten,
> > die ankommende Nachricht tr�gt knapp 2/3 Ballast im Verh�ltnis zur
> > tats�chlich nutzbaren Information.
>
> Ist der Platz auf Deiner Harddisk so knapp?
Er war es. Meine Messagebase n�hert sich aber bereits wieder der 10-
MB-Grenze. Es geht um Resourcenschonung; egal, wie billig HDs inzwi-
schen sind, man mu� den Platz nicht mit unben�tigten Informationen
blockieren.
Blo�, weil ich mir den Sprit leisten kann, heize ich ja auch nicht
mit Vollgas �ber die Autobahn - das zeitigte eben auch noch gewisse
Nebeneffekte.
> Klar, bei Kurzpostings ist der Header groesser als das Posting, allerdings
> kommen ja einige Eintraege ja erst im Lauf des Versands zusammen.
Und bei eingehenden Nachrichten tragen diese die Eintr�ge bereits,
ja.
> Zum Traffic: Wie gesagt, ein Teil dieser Headerinformationen kommt erst im Lauf
> des Versands hinzu, abhaengig davon, wo die Mail geroutet wird.
Es geht um die eintreffenden Nachrichten, nicht um die ausgehenden.
> Moment: Ich weiss ja nicht, was Du mit Microdot alles liest. Auf jeden Fall lese
> ich eine ganze Reihe von Newsgroups damit. Und wenn ich da poste, gibts ab und
> an Spam, der bei mir aufschlaegt. So gehts wohl auch anderen. Und da finde ich
> es sinnvoll, die Header analysieren zu koennen.
Nochmal: Es geht um eine zus�tzliche Option, kein ge�ndertes Pflicht-
verhalten. Wenn Du alle Header behalten willst, beh�ltst Du sie eben,
aber der nicht daran Interessierte k�nnte sie andernfalls l�schen
lassen. Es gibt neben Dir und mir auch eine Menge User, die Spam ein-
fach killen, ohne den Verursacher tracen zu wollen.
> > Das ist nur ein Beispiel. Ein anderes ist der User, der z. B. gene-
> > rell nicht vorhat, etwas anderes mit den eingehenden Nachrichten zu
> > machen als sie zu lesen. Wozu sollen dann nicht ben�tigte Header
> > sinnlos Platz in der Datenbank beanspruchen?
>
> Nun, der loescht ja die Spam-Mails ohnehin, also wird dieser Platz wieder frei.
Ach - und was ist mit den Nachrichten, die er beh�lt? Bei mir beste-
hen News Gott sei Dank noch nicht aus 100% Spam.
> > Ich hielte eine Option wie "Stripheader" f�r so verkehrt nicht.
>
> Ob er wirklich den Header kuerzen sollte? Ich waere eher dafuer, dass in der
> Normalansicht weniger vom Header angezeigt wird. Vorhandensein sollte er aber
> schon.
Stell Dir doch mal bitte einen Teilnehmer vor, der v�llig unbedarft
und unbeleckt von technischen Gegebenheiten einfach blo� seine News
lesen m�chte, nichts weiter. (Ich wei�, sowas nennt sich im allgemei-
nen zwar "PC-User", aber dennoch... <eg>)
F�r den sind besagte Header �berfl�ssig wie ein Kropf. - Ich w�rde so
etwas nicht sagen, wenn ich solche Leute bei mir nicht h�tte.
[MIME]
>
> > Die Integration wenigstens rudiment�rer Routinen w�re trotzdem w�n-
> > schenswert. Abver dar�ber brauchen wir gar nicht erst zu diskutieren,
> > das kommt sowieso nicht (mehr) - jedenfalls nicht f�r MicroDot.
>
> Ok, Du hast recht, es waere eine gute Idee.
> Aber: Warum kommt das nicht mehr?
Weil eine Integration einen Aufwand bedeuten w�rde, den Oliver nicht
mehr in MicroDot investieren m�chte, wie er sinngem�� mehrmals gesagt
hat.
Wenn schon, dann richtig, hat er geschrieben und die MIME-Implementa-
tion f�r MicroDot II vorgesehen.
--
Bye; Kai
_____________________________________________________________
MicroDot-Mailing-Liste - Info & Archiv: http://www.vapor.com/
ML-Hilfe: <[EMAIL PROTECTED]>, Inhalt "HELP"
ML-Abbestellen: <[EMAIL PROTECTED]>, "UNSUBSCRIBE"
