Joachim Merkel <[EMAIL PROTECTED]> wrote on 22.07.04:
> Michael Heydekamp ([EMAIL PROTECTED]) schreibt:
>> 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.
Der UUZ erzeugt den schon immer bei Bin�rnachrichten, aus denen er sich
selbst eine MIME-Nachricht backt. Ich habe dessen Form jetzt etwas
angepa�t und die soll sp�ter auch in XP Verwendung finden:
----------8<----------
MY:
- (-zu): MIME-Boundary (wird bei der Konvertierung von mit "i" auf
Userbrett in XP erzeugten Bin�rnachrichten in eine Multipart-Nachricht
erzeugt) an die in den MIME-Multipart-Routinen von FreeXP verwendete
Fassung angeglichen und als eigene Funktion nach mimedec.pas verlagert
(zwecks sp�terer Verwendung auch in FreeXP). Das Boundary hat jetzt
die Form "-==_FreeXP_Next_MIME_Part_[Zufallsstring]_==-".
UUZ.PAS, UUZ0.PAS, MIMEDEC.PAS
----------8<----------
�nderung gegen�ber dem bisherigen Boundary in XP ist der angeh�ngte
Zufallsstring (den der UUZ bei "seinem" Boundary schon immer benutzt
hat).
>> 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.
Klar, aber wie ich die ermittelten Parmeter und deren Werte dann
(weiter)verarbeite, ist die Frage.
Bisher gab es einen MIME-Record, dort war f�r jeden bekannten Parameter
eine Variable mit fester L�nge hinterlegt (siehe 'hd.mime.charset'
z.B.). Dieses Verfahren hat aber den Nachteil, da� man alle
existierenden Parameter auch kennen mu�, ansonsten gehen die unbekannten
verloren.
Und alle zu kennen, kann man nie gew�hrleisten. Also stelle ich mir im
Moment paarige Records mit Bezeichner und Wert vor. In einer
verketteten, dynamischen Liste kann man das speicherschonend - wenn auch
nicht sehr bequem - verarbeiten.
>> 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.
Ich denke eher, da� ich f�r die paar Parameter, die ggf. angepa�t oder
ausgetauscht werden m�ssen, zus�tzlich eigene Variablen definiere (die
brauche ich ja sowieso, um irgendwo den neuen Wert herzuholen).
Und beim Schreiben des Headers, den man sich aus der verketteten Liste
(s.o.) baut, schaut man dann, wenn man dort z.B. gerade beim Parameter
"charset" angekommen ist, ob die Variable hd.charset einen Wert hat und
wenn ja, schreibt man diesen Wert, ansonsten den Wert, den man im Record
der verketteten Liste selber findet.
>> 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
Ja. Bei 1. habe ich z.B. etwas vergessen:
>> 1) "name=" oder "x-filename=" in Content-Type => "FILE:" (Pfad
>> entfernen)
wenn Content-Type <> external-body.
Den Dateinamen im Parameter "name=" nach FILE: zu schreiben, w�re bei
external-body recht sinnfrei wenn nicht falsch. Die Nachricht enth�lt
keine Datei.
>> -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.
Das wei� der UUZ in zu-Richtung ja nicht, ob sie dem Empf�nger bekannt
sind, also kann er sie nicht einfach entfernen.
Die Frage "Wollen/k�nnen wir das?" bezog sich auf das Entfernen von im
jeweiligen Kontext nicht standardisierter/definierter Parameter. Z.B.
gibt es bei app/o-s den Parameter "padding=", aber eben auch nur dort.
K�me er bei multipart/related vor, k�nnte man ihn theoretisch entfernen,
weil undefiniert.
Aber auch das w�rde voraussetzen, da� wir sicher sind, alle Parameter zu
kennen, und da das nicht der Fall ist, ist die Frage nach dem K�nnen IMO
eher mit "nein" zu beantworten.
Michael
------------------------------------------------------------------------
FreeXP Entwickler-Mailingliste
[EMAIL PROTECTED]
http://www.freexp.de/cgi-bin/mailman/listinfo/dev-list
