Thread Serialize Algorithmus (18 answers)
Opened by rosti at 2014-02-07 13:04

rosti
 2014-02-07 17:20
#173460 #173460
User since
2011-03-19
3211 Artikel
BenutzerIn
[Homepage]
user image
Ach was ;)
Wenn der Algorithmus steht, gibt es so gut wie nichts zu debuggen.
Das hier: http://rolfrost.de/blobview.html hat auf Anhieb funktioniert.

Gzip: Ok, aber guck Dir mal auf MDN das Blob-Objekt an. Es hat im Konstruktor den optionalen Content-Type, da gibts auch einen Default. Wenn Du also Gzip anforderst und einen xhr.responseType = 'blob'; dann hast Du quasi nur EINEN Content-Type. Für Multipart-Content müsstest Du auf diese Art und Weise mehrere Requests machen. Genau hier setzt meine Idee an:

Multipart-Content als xhr.responseType = 'arraybuffer' requesten. Da können dann mehrere Content-Types drinstecken, was letztendlich nur EINEN Request erfordert. Interessant ist, wie MDN den Umgang mit einer Binary imlementiert: Im DOM wird ein Token generiert, der eindeutig ist, z.B. blob:af975c28-25f3-4e49-b8cc-4dee8efcdaea was einem DOM-Element (audio, video, image) als URL-Attribut zugewiesen werden kann. Eine diesbezügliche Response enthält nicht etwa base64-(oder anderweitig gepackte)Daten sondern native Binaries. Zusammen mit Text und wenn's ein bischen mehr sein darf auch zusammen mit JSON, XML usw. was Letztere jedoch überflüssig macht, weil es einfacher geht.

Das ist die Idee. Und wenn ein Browser (JavaScript) mit Storable::freeze oder Sereal-Binaries umgehen kann, das wäre echt der Hammer! Das würde auch Perl als Programming
Language einiges an Punkten bringen, davon bin ich überzeugt!!!

--Rosti

View full thread Serialize Algorithmus