POST an OData Service mit PHP Klasse

[1UnitedPower]

Hakuna matata!

Einen Dump (ähnlich JSON) muss eine Maschine komplett in den Hautpspeicher laden, damit er geparst werden kann (gilt auch für XML).

Nein, das ist falsch.
Siehe dir zum Beispiel mal die Bibliothek json-parse-steam auf Github an. Oder im Falle von HTML/XML: htmlparser2.

Vergleich das mal Hiermit. Ein Serializer arbeitet nicht mit Tokens, sondern mit Längenangaben (8, 16, 32, 64 Bit).

Sowohl der JSON-Parser als auch der XML-Parser, die ich dir gezeigt habe, können Datenstreams on-the-fly parsen. Jetzt schmeckt dir die Implementation nicht?

JS kennt zwar den ArrayBuffer und DataView, aber ich habe nichts dergleichen in o.g. Sourcen gefunden.

Wieso auch? Nur zum Selbstzeck?

Und JSON- und XML-Parser gibt es bereits fertig implementiert für jede Programmierumgebung. Wieso sollte man das Rad neuerfinden?

Unsinn. Wer mit Bytes operiert, erfindet doch das Rad nicht neu.

Okay, dir fehlen scheinbar einige Grundlagen.

Bytes ohne Angabe über die Kodierung sind wertlos. Kein Mensch oder Computer der Welt kann was mit Binärsequenzen anfangen, wenn man ihm nicht sagt, wie er die Daten zu interpretieren hat. Dafür braucht man mindestens noch eine Zusatzinformation: Die Kodierung. Ein paar Beispiele, um dir das klar zu machen:

Fließkommazahlen können als Double-Precision-Floating-Point gespeichert werden.
Strings können in UTF8, UTF16 oder ASCII kodiert sein.
Videos können OGG kodiert sein.
Audiodateien können MP3 kodiert sein.
DOM-Dokumente können XML oder HTML kodiert sein.
Datenstrukturen (zumindest einige) kann man als JSON kodieren.

Alle diese Dinge werden auf der Festplatte oder im Hauptspeicher irgendwie als Sequenzen von Bytes gespeichert. Wenn man nicht dazu sagt, WIE diese Bytesequenzen zu verstehen sind, dann kann man mit den Daten auch nichts anfangen. Das WIE ist also wichtig, das sagt uns, dass es sich um eine Video handelt und wie man dieses abspielen kann.

Den Vorgang eine Bytesequenz in eine verwertbare Datenstruktur zu überführen nennt man Dekodieren. Im Falle von Austauschdatenformaten oder Programmiersprachen spricht man auch oft von Parsern. Den umgekehrten Vorgang Datenstrukturen in Bytesequenzen zu überführen, nennt man kodieren oder serialisieren

Das Ergebnis einer Kodierung muss nicht gleich eine Binärsequenz sein. Ebensowenig müssen die Eingabedaten für eine Dekodierung immer Binärsequenzen sein. Es ist üblich, dass man verschiedene Kodierungen schichtet, zum Beispiel: DOM-Dokumente können HTML kodiert werden, die HTML-Zeichenkette kann dann UTF8 kodiert werden, um eine Binärpräsentation der Daten zu erhalten.

Wenn ein Webservice ein Datenaustauschformat unterstützen will, sei es XML, JSON oder dein selbstgestricktes hotti-eav-binär-Format, dann muss auf der serverseite also ein Kodierer/Serialisierer existieren. Auf der clientseite muss ein Dekodierer/Deserialisierer/Parser existieren.

Für JSON und XML sind sowohl Kodierer als auch Dekodierer weit verbreitet. Für dein benutzerdefiniertes Format gibt es, außer deiner eigenen Implementation, keine weitere Bibliotheken.

Um dein Statement nochmal aufzugreifen:

Unsinn. Wer mit Bytes operiert, erfindet doch das Rad nicht neu.

Wenn man für jede Umgebung erst einen eigenen Kodierer und Dekodierer implementieren muss, dann kann man sagen, dass man das Rad neuerfindet.