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

Antwort per Email an