Michael Heydekamp ([EMAIL PROTECTED]) schreibt:
[...]
> Mit "Auswerten" meine ich die Prüfung auf einen konkreten Parameter
> nach dem Prinzip "if parname='boundary' then hd.boundary:=[...]".
> Nur die Parameter, die so ausgewertet wurden, blieben bisher in
> zu-Richtung erhalten, alle übrigen fielen unter den Tisch. Das
> kann's ja nicht sein.
So hatte ich das auch verstanden, bisher wurde fast alles weggeworfen.
> Schon gar nicht vor dem Hintergrund, daß mir vorschwebt, mit FreeXP
> mal ein "echtes" N/W/* machen zu können, ohne die ursprüngliche
> Struktur (Content-Type, Boundary usw.) zu verletzen und durch eine
> eigene zu ersetzen. Darauf wäre dann wenigstens der UUZ schon mal
> vorbereitet.
Liest sich plausibel, auch der Wunsch nach einem eindeutigen
Boundary-Delimiter wird bisher übergangen.
Ob man sich unter einer ZConnect-Box immer Freunde schafft, alles
so weiterzuleiten was die Gates abliefern, bleibt immer fragwürdig.
PM hat sich seit jeher nicht damit anfreunden wollen, XP zur
Gateway-Software zu stilisieren.
[...]
> Ich bin mir einfach auch noch nicht darüber im klaren, mit welcher
> Datenstruktur ich arbeiten soll. Entweder liest man alle Parameter
> (Bezeichner und Wert jeweils in einem Record) in eine verkettete
> Liste oder sowas ein und baut daraus später wieder den Header
> zusammen, oder man behandelt das als einen gesamten String.
Ich verstehe jetzt nicht genau, was Du ansprichst.
Um die Parameter zu parsen hast Du doch den Header komplett
erstmal als String einzulesen.
> Da ich aber natürlich hier nicht auf einen Pascal-String beschränkt
> sein will, läuft's wieder auf ein array of char mit 65500 Zeichen
> hinaus. Aber da sehe ich das Problem, wenn sich die Stringlänge
> (z.B. beim Austausch von "charset=UTF-8" durch
> "charset=ISO-8859-15") ändern sollte, daß das dann nicht geht, wenn
> ich mir vorher nur den Speicher für die aktuelle Länge des Headers
> reserviert habe.
Änderungen können vielleicht in verkettete Strings abgespeichert
werden. Zunächst also wird Speicher mit der Länge des vorhandenen
Strings zusätzlich reserviert. Wenn also eine Änderung vorgenommen
wird, wird der String bis an die Stelle kopiert wo die Änderung
vorgenommen wird. Dann wird die Änderung reinkopiert. Wenn diese
länger ist als Speicher angefordert wurde, wird nur der Teil
umkopiert, der reinpaßt, dann wieder dasselbe und nachher wird
alles der Reihe nach auf die Platte geschrieben.
> Und jedes Mal die vollen 64k zu holen wäre pure Verschwendung,
> vorsichtshalber ein paar Bytes (wieviel?) mehr als die aktuelle
> Länge hingegen willkürlich und nie sicher, daß es reicht. Ja gut,
> doppelt soviel sollte wohl immer reichen, aber solche
> "Kalkulationen" sind auch irgendwie Murks.
Besser wäre, die Sache kann (etwas) dynamisch(er) passieren.
> Ich fange einfach mal an, konkret ein paar Dinge zusammenzustellen.
> Falls jemand was ergänzen/korrigieren möchte, bitte ich darum. :)
> -uz: Content-Type und Content-Disposition parsen und ...
[...]
> 6) Content-Type und Content-Disposition mit originalem Inhalt
^ soll wahrscheinlich 7) heißen
> und Prefix "U-" schreiben
> -zu: U-Content-Type und U-Content-Disposition parsen und ...
[...]
> 3) Alle Parameter entfernen, die a) bekannt sind und b) im
> jeweiligen Kontext nicht standardisiert sind ("x-"
> hingegen erhalten)
> (Wollen/können wir das?!?!?)
"x-"-Parameter sollen dem Empfänger bekannt sein, sonst kann man sie
sich sparen.
[...]
> Your turn. :)
Kann eine Weile dauern bei mir, denn zum einen ist der erreichte
Stand bei XP in punkto MIME schon um einiges besser als ich es
benötige, aberin Hinblick auf die weitere Dokumentation werde
ich natürlich auch darauf achten.
--
Salut
_)oachim
------------------------------------------------------------------------
FreeXP Entwickler-Mailingliste
[EMAIL PROTECTED]
http://www.freexp.de/cgi-bin/mailman/listinfo/dev-list
