nicht angemeldet
Hakuna matata!
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?
Siehe meine erste Anmwerkung zu diesem Thema: Die OData-Entwickler erfinden das Rad neu. Mit wenigen Zeilen Perl kannst Du ganze Datenbanken via HTTP übertragen. Diesbez. Serializer und Low-Level-HTTP-Client gibt es seit Jahren.
Bytes ohne Angabe über die Kodierung sind wertlos.
Bytes kennen überhaupt keine Kodierung. Andererseits kannst Du selbstverständlich auch diese Informationen übertragen. Und was mit Perl geht, das geht auch mit anderen PLs.
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.
Es gibt Perl-Versionen, da ist der im Core mitgelieferte Serializer nicht kompatibel. Für mich kein Grund, auf XML umzusteigen, ein eigener Serializer für zyklische Strukturen ist denkbar einfach gestrickt.
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.
Es gibt sogar in Sachen Serializer einige Neuentwicklungen auf CPAN.
Und nochwas zum Thema MIME: Meine Maildatei der Zukunft wäre eine Hyper-Media-Datei (Multipart), die den 8-Bit-Bereich nutzt und sowas wie Trennlinien (Boundary), Base64 oder Quoted-Printable gar nicht braucht. Ich wäre kein Entwickler, wenn ich bisherige Standards und auch eigene Entwicklungen nicht kritisch betrachten würde. Darüber hinaus war es in der Geschichte schon immer so, dass 'Standards' nicht unbedingt den neuesten Stand der Entwicklung repräsentieren. Siehe VE 301: Etwa zur selben Zeit von Loewe entwickelte Radios, bestückt mit Mehrfachröhren (v. Ardenne) hätten die Bezeichnung Volksempfänger weit mehr verdient.
Schöne Grüße.