Opened by lichtkind at 2016-05-01 23:24
Die Kontrollstruktur meines hier vorgestellten Parsers zeigt die Unabhängigkeit vom gesendeten Enctype. Wobei es natürlich wenig sinnvoll ist, bei der Übertragung von Text auf application/json umzuschalten. Das ganze Geheimnis eines binary safe Serialize-Algorithm besteht darin, mittels pack() die Längenangaben von Werten auf einheitlich 4 Byte zu bringen. D.h., die kleinste Einheit wäre pack("N", $value).$value wobei nur noch festzulegen wäre, wie mit undef vs. Leerstrings umgegangen werden soll.
Entweder über ein zusätzliches Byte oder eine Vereinbarung like NOT NULL. Ansonsten liefert $self->param('name') immer dasselbe egal ob POST, GET, PUT oder eine andere exotische Requestmethode und auch egal, welcher Enctype vom Client benutzt wird.
Zweifellos grottig ist der Enctype multipart/form-data, insbesondere ist die Verwendung einer Boundary mehr als umständlich innerhalb einer auf die Verarbeitung von Bytes ausgerichtetetn Programmierung. Viel effizienter ist es, mit Längenangaben zu arbeiten, das vereinfacht den Parser und macht die Boundary gar überflüssig:
Mit Längenangabe: Der Parser liest bytegenau die Binary aus der Gesamtsequenz, fertig.
Mit Boundary: Der Parser muss byteweise durch die Sequenz gehen solange bis die Boundary erkannt wurde und muss danach die Boundary wieder abschneiden.
Und überhaupt sind zeichenorientierte "Verpackungen" ineffizient, den in PHP üblichen Serialize-Algorithmus, der auch als CPAN-Modul zu haben ist, habe ich mal mit anderen Serializern verglichen, er schneidet von allen als Schlechtester ab.
Im Übrigen hat kein Geringerer als Niklas Wirth bereits um 1980 darauf hingewiesen, dass Random Access (Wahlfreier Zugriff) nicht in einer Byte-Sequenz sondern im Hauptspeicher abgebildet wird. Zwischen Beiden vermittelt ein Algorithmus.
PS: Mein Content Management bis hin zum Remote DB-Management mach ich schon seit Jahrzehnten über HTTP/Webservices und Perl auf Beiden Seiten. Auf die Idee, eigene Serializer zu bauen, bin ich zwangsläufig gekommen, nachdem ich feststellen musste dass Storable::freeze/thaw Kompatibilitätsprobleme hat und ich mich von daher nicht darauf verlassen kann, dass Daten auf verschiedenen Plattformen/Perlversionen fehlerfrei wiederhergestellt werden können.
Last edited: 2016-05-03 17:20:05 +0200 (CEST)
Entweder über ein zusätzliches Byte oder eine Vereinbarung like NOT NULL. Ansonsten liefert $self->param('name') immer dasselbe egal ob POST, GET, PUT oder eine andere exotische Requestmethode und auch egal, welcher Enctype vom Client benutzt wird.
Zweifellos grottig ist der Enctype multipart/form-data, insbesondere ist die Verwendung einer Boundary mehr als umständlich innerhalb einer auf die Verarbeitung von Bytes ausgerichtetetn Programmierung. Viel effizienter ist es, mit Längenangaben zu arbeiten, das vereinfacht den Parser und macht die Boundary gar überflüssig:
Mit Längenangabe: Der Parser liest bytegenau die Binary aus der Gesamtsequenz, fertig.
Mit Boundary: Der Parser muss byteweise durch die Sequenz gehen solange bis die Boundary erkannt wurde und muss danach die Boundary wieder abschneiden.
Und überhaupt sind zeichenorientierte "Verpackungen" ineffizient, den in PHP üblichen Serialize-Algorithmus, der auch als CPAN-Modul zu haben ist, habe ich mal mit anderen Serializern verglichen, er schneidet von allen als Schlechtester ab.
Im Übrigen hat kein Geringerer als Niklas Wirth bereits um 1980 darauf hingewiesen, dass Random Access (Wahlfreier Zugriff) nicht in einer Byte-Sequenz sondern im Hauptspeicher abgebildet wird. Zwischen Beiden vermittelt ein Algorithmus.
PS: Mein Content Management bis hin zum Remote DB-Management mach ich schon seit Jahrzehnten über HTTP/Webservices und Perl auf Beiden Seiten. Auf die Idee, eigene Serializer zu bauen, bin ich zwangsläufig gekommen, nachdem ich feststellen musste dass Storable::freeze/thaw Kompatibilitätsprobleme hat und ich mich von daher nicht darauf verlassen kann, dass Daten auf verschiedenen Plattformen/Perlversionen fehlerfrei wiederhergestellt werden können.
Last edited: 2016-05-03 17:20:05 +0200 (CEST)