Joachim Merkel <[EMAIL PROTECTED]> wrote on 24.10.04:
> Michael Heydekamp ([EMAIL PROTECTED]) schreibt:
>>> Ist klar. Vor der Forderung nach unbedingter Exaktheit stehen schon
>>> mal Fragen der Ziel-Mittel Relation, Effizienzbetrachtungen und die
>>> Einbeziehung der Vorarbeiten anderer,
>> McKinsey-Jargon ist nicht mein Ding.
> War was unklar?
N� n�, ist schon alles klar... <g>
>> Mit einer Sache k�nnte sich aber tats�chlich mal jemand besch�ftigen,
>> wenn er m�chte: Die Routine 'EncodeFoldQuote' in uuz.pas m��te
>> hinsichtlich der Unterst�tzung beliebig langer ZConnect-Header noch
>> dahingehehend angepa�t werden, da� sie als *Input* eben auch solche
>> beliebig langen Headerzeilen (also char-Arrays bis 65500 Zeichen)
>> verarbeitet, da wir diese ja jetzt auch *ausgehend* unterst�tzen.
>> Bisher kann sie aus mehreren Einzelstrings (z.B. mehrere KOP:-Header)
>> zwar einen beliebig langen RFC-Header generieren, aber als Input eben
>> jeweils nur einen Pascal-String verarbeiten.
> Ich habe mir einmal so einen Quick&Dirty-Job angetan, als ich
> DocForm umgebaut habe.
Um quick&dirty geht's eigentlich gerade nicht.
> Ich kann es mir mal anschauen, aber viel Hoffnung ist da da nicht dran
> zu kn�pfen. Es hie� mal vor �ber einem Jahr, der UUZ sei bald fertig
> und ich k�nne mit dem Profiler damit "rumspielen", das habe ich ein
> wenig getan.
Definiere "fertig".
Er war "fertig", wie jeder vorherige UUZ auch "fertig" war. Bis dann
dies auftauchte, dann jenes, umfassende Umbauten hinsichtlich Multibyte-
Decodierung erforderlich wurden, die XP2-Unterst�tzung implementiert
wurde, jetzt kam noch die mbox-Unterst�tzung hinzu (und zwar eine echte,
die im Unterschied zu der von OpenXP auch funktioniert), und und und...
Ist ja alles penibel dokumentiert, was soll ich das alles hier
aufz�hlen.
So gesehen, ist Software nie "fertig". Wenn Du mit "fertig" meinst, da�
die Garantie besteht, da� der Source nie wieder in diesem Leben
angepackt werden mu�, dann garantiere ich Dir, da� dieser Stand nie
erreicht werden wird.
> Generell kann ich mich schon als gut vorbereitet betrachten, aber
> direkt da reinspringen m�chte ich nicht.
Ist ok. Dann mu� aber auch klar sein, da� ich es machen werde und mu�,
und sich dadurch andere Dinge halt wieder verz�gern. Nur schon mal
vorbeugend.
> Dummerweise ist der UUZ nie fertig geworden,
Doch, siehe oben.
>> Au�erdem war noch die Recherche in Sachen Content-Type-Parameter ein
>> Thema, das ich mal angesprochen hatte und mir Zeit sparen w�rde.
> Tja, ich hatte wohl mal geschrieben, das es ein paar Vendor-Typen
> gibt, viel ist da nicht auf dem IETF-Server.
Finde ich schon, aber es geht nicht um eine Aufz�hlung der Typen, die
ist ja dort vorhanden. Es geht um die Kl�rung, wie die im einzelnen vom
UUZ -- z.B. hinsichtlich Charset-Konvertierung -- *behandelt* werden
sollten (speziell die diversen text/*), aber das hatte ich in dem Thread
eigentlich alles schon en detail erl�utert.
> Ich glaube nicht, da� es weltbewegendes von mir dazu zu vermelden
> gibt.
Kein Thema, mache ich dann halt auch selbst. Wird dann aber... siehe
oben zu 'EncodeFoldQuote'.
Soll nur hinterher speziell MK nicht wieder sagen, ich w�rde wie eine
"Glucke" �ber allem h�ngen. Wenn's keiner macht, mu� ich's ja machen.
> Ich lese das nochmal nach, vergessen hatte ich es nicht. Vielleicht
> kann ja Heiko dazu was beitragen oder jemand kennt irgendwelche
> Protokolle aus Standardisierungsgremien oder findet eine amerikanische
> Master-Thesis mit Hinweisen dazu auf irgendeinem Server.
Heiko wer? Und was wissen irgendwelche Standardisierungsgremien �ber
den UUZ bzw. was haben die damit zu tun?
Michael
------------------------------------------------------------------------
FreeXP Entwickler-Mailingliste
[EMAIL PROTECTED]
http://www.freexp.de/cgi-bin/mailman/listinfo/dev-list
