Meine Herren!

Das ist eine weitere Spezialisierung, die du vornimmst und die hier keinen effektiven Mehrwert erzeugt. Mit dem Ansatz, den ich hier bewerbe, kannst du völlig agnostisch davon arbeiten,

Das kann ich auch, schließlich ist ein Serializer auch nichts weiter als eine Möglichkeit zur Datenabstraktion, nämlich für den Transport zum Erzeugen von Sequenzen.

Das kannst du nicht, bei dir müssen Server- und Client-Software jeweils genaue Kenntnis voneinander haben. Das ist eine logische Folgerung daraus, dass du keinen expressiven MIMEType überträgst, der es Server oder Client ermöglichen könnte eine eigene Interpretation der Daten anzustellen.

ob die Daten textlich oder binär weiterverarbeitet werden.

Eine mit textlichen Mitteln vorgenommene Serialisierung berührt den Layer Darstellung, im Fall JSON gar ist Code das Mittel für den Transport.

Verschiedene Kodierungen für die selben Daten, haben immer eine andere Gestalt, eine andere Repräsentation. Diese Repräsentation, völlig unabhängig davon, ob sie binär oder textuell ist, ist immer Teil der Darstellungsschicht, im Sinne des OSI-Modells.

Eine Low-Level-Serialisierung jedoch findet auf Byte-Ebene statt, dieser Layer hat weder mit Datentypen noch mit Zeichen noch mit Code oder anderen Inhalten zu tun.

Low-Level und High-Level verläuft hier nicht zwischen textuell und binär. Du ignorierst das Potenzial von HTTP zum Übermitteln des MIMETypes. Der MIMEType ist aber wichtig, er teilt dem Kommunikationspartner mit wie die Daten zu verstehen sind, wie er sie interpretieren soll. Low-Level wäre es, davon Gebrauch zu machen. Du verschleppst diese Information aber, du vereinbarst sozusagen eine stillschweigende Übereinkunft von Client und Server, dass die Daten im Sinne deiner benutzerdefinierten Kodierung zu verstehen sind. Auf diese Art formalisierst du deine eigene HÖHERE Protokollschicht.

Schließlich haben sich die Entwickler des OSI-Referenzmodells auch was dabei gedacht.

Und du arbeitest genau gegen diese Trennung der Verantwortlichkeiten, die im OSI-Modell verankert werden. Wenn du das OSI-Modell schon anführst: Wieso nimmst die Aufgaben der Darstellungsschicht in die Verantwortung der Anwendungsschicht? Genau das machst du nämlich.

Hast Du Dir meine Beispiele mal angeguckt, wie einfach das letztendlich wird, Texte zusammen mit Binärdaten per HTTP zu übertragen? Wenn ich das mit herkömmlichen "Standards" machen müsste, wirds wesentlich komplizierter. Und genau das ist das Ziel meiner Entwicklungen.

Ich finde genau das Gegenteil ist der Fall. Du machst dir Arbeit, wo keine sein muss. Hier ist ein komplettes Beispiel, wie man das erreichen kann:

<form action="foo" enctype="multipart/form-data">  
   <input name="textdaten">  
   <input type="file" name="binärdaten">  
   <button>Abschicken</button>  
</form>

Wie geht es denn bitte noch einfacher?

Diese Verantwortlichkeit bleibt ganz alleine bei dem Kodierungs-Algorithmus liegen.

Ja klar, wo denn sonst ;)

Ich meinte damit die Kodierung, die man im HTTP-Header übermittelt. Du defninierst nur application/octet-stream und triffst dann Annahmen über die tatsächlich enthaltenen Daten.

Das nennt sich Seperation of Concerns.

Eine Doktorarbeit könnte ich auch schreiben. Ich bin aber eher der Praktiker.

Die Theorie findet ihre Anwendung in der Praxis und die Praxis motiviert die Theorie.

Interessant wird eine Low-Level-Serialisierung

Du bist nicht Low-Level. Du argumentierst ja gerade für eine höhere Software-Schicht, ich argumentiere dagegen.

Nein eben nicht, siehe weiter oben.

Eben doch, siehe weiter oben.

Ein herkömmlicher Parser nimmt den Parameter-String (oder die POST Daten) komplett in den Hauptspeicher um ihn in die Einzelteile zu zerlegen.

Mit Parser meinst du einen Dekodierer. Und dass alle Daten, die verarbeitet werden sollen in den Hauptspeicher geladen werden müssen steht außer Frage. Das wirst du auch nicht umgehen können.

Bei multipart/form-data wird, sofern die Komponente den file-Parameter drin hat, eine temp. Datei angelegt. Das kostet CPU, IO und RAM.

Das ist keine technische Notwendigkeit und auch kein spezifiziertes Verhalten. Du argumentierst gegen einzelne Implementationen. Aber der Flaschenhals einer Webanwendung liegt ohnehin nicht bei den Schreib/Lese-Vorgängen auf das lokale Dateisystem des Servers, sondern in Bandbreite der Netzwerk-Schnittstelle.

Ein Low-Level-Serializer hingegen verzichtet auf rechenintensive Stringoperationen, er erzeugt für Längenangaben Bytes (JS: ArrayBuffer, DataView) oder liest Bytes (PHP, Perl: pack, unpack).

Low-Level-Serialisierer ist falsch. Du meinst einfach nur eine Kodierung mit binärer Repräsentation der Daten.

Die Bytes der Nutzdaten werden entweder aus einem Handle gelesen oder in ein Handle geschrieben.

Das Konzept von einem handle gibt es auch bei Dateioperationen. Ich weiß nicht, worauf du hinaus möchtest.

Während der Übertragung ist das Handle ein Socket, am Server angekommen, ist es STDIN. Von Perl oder PHP ausgehend ist es dann STDOUT in Richtung Webserver und dann wieder das Socket

Und?

das ist CPU- und RAM-gefällig und verzichtet auf temporäre Dateien (Siehe auch meine diesbez. Sicherheitsbetrachtungen).

Mit solchen Performanz-Aussagen musst du vorsichtig sein, hast du Benchmarks oder theoretische Erörterungen darüber, die dir das bescheinigen?

Ich stelle zunächst nur Überlegungen erster Ordnung an und freue mich darüber, dass moderne Browser mit Binärdaten umgehen können.

Konnten sie schon immer. Neu ist die JavaScript-API um mit binären Daten zu arbeiten und die nutzt du, um natives Verhalten nachzubauen. Wirklich interessant sind diese APIs bei clientseitigen Problemen, wie bei WebGL, wo performante Programmierung einen hohen Stellenwert erfordert.

Btw. alle Inhalte meiner Website (370 HTML-Seiten) liegen ebenfalls in einer Binärdatei.

Zu den Interna deines Frameworks kann ich nichts sagen, ist ja nicht offen.

PS: Respekt vorm Alter erwarte ich nicht, die 58 siehst Du mir ohnehin nicht an ;)

Jeder in diesem Forum, der an einer aufrichtigen Debatte interessiert ist, genießt meinen Respekt, unabhängig von Alter, Wissensstand und sonstigen Einflüssen, du zählst auf jeden Fall dazu ;)