Opened by rosti at 2014-02-07 13:04
User since
2011-03-19
3212 Artikel
BenutzerIn
![[Homepage]](/battie/theme/default/homepage.gif)
2011-03-19
3212 Artikel
BenutzerIn
Beispiele wären sehr hilfreich.
Mal ein bischen übern Tellerrand geschaut: Die neuen Features moderner Browser ermöglichen Ajax mit reinen Binärdaten, Objekt ArrayBuffer.
Es ist möglich, in ArrayBuffer komplexe Datenstrukturen zu übertragen, als Multipart-Content in einer einzigen Binary serialisiert.
Serverseitig hätten wir z.b. sowas:
Nun, es ist naheliegend, einen Serializer wie Storable o.ä. zu nehmen um das als Response zu senden anstatt einen eigenen Serializer zu implementieren. Was wir brauchen, ist ein Deserializer in JavaScript, wo obenstehende Struktur deserialisiert in einer Datenstruktur im DOM landet.
Damit können auch neue HTML5-Elemete wie audio, video mit Daten betankt werden, ich habe das mit einem proprietären Serializer/Deserializer getestet und das funktioniert einwandfrei. Nichts produktives, nichts aufregendes und nur Hobby.
Interessant wirds das erst, wenn JS im DOM mit einer Binary zurechtkommt, die mit Perl/serverseitig per Storable::freeze oder Sereal o.ä. erzeugt wird. Sozusagen Perl-Standards in den Browser hinein verlängern.
Wenn ich in den nächsten Tagen dazu komme, gehe ich das mit Storable und o.g. Hash of Hashes an. Mein Verständnis für c muss ich sehr auffrischen, ist schon ne Weile her ;)
Der Gewinn gegnüber XML, JSON, YAML u.a. liegt in einem kleineren Bandbreitenbedarf und einem besserern Verhältnis zwischen Nutzdaten/Verpackung, was für mobile Endgeräte auch in Zukunft eine Rolle spielen dürfte.
Genauso möglich: PHP serialize('Quellcode liegt offen'). Na, vielleicht mach ich das als Erstes, aber Perl ist mir letztendlich lieber ;)
Edit: PHP.serialize() ist irreführend, das ist zwar binary-safe aber zeichenorientiert und nicht im Sinne einer Sequenz nach Niklaus Wirth; was aber nicht heißen soll, dass ich jetzt auf Pascal umsteige ;)
Last edited: 2014-02-08 09:21:26 +0100 (CET)
Mal ein bischen übern Tellerrand geschaut: Die neuen Features moderner Browser ermöglichen Ajax mit reinen Binärdaten, Objekt ArrayBuffer.
Es ist möglich, in ArrayBuffer komplexe Datenstrukturen zu übertragen, als Multipart-Content in einer einzigen Binary serialisiert.
Serverseitig hätten wir z.b. sowas:
Code (perl): (dl
)
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19
'entity01' => { type => 'text/plain', title => 'Foo', descr => 'Foo description', body => 'This is Foo...', }, 'entity02' => { type => 'application/pdf', title => 'EAV Draft', descr => 'Serialize complex data structures into binary sequences...', body => $pdf_string, }, 'entity03' => { type => 'audio/mp3', title => 'Perfect Strangers', descr => 'Those where the days...', artist => 'Deep Purple', body => $mp3, }
Nun, es ist naheliegend, einen Serializer wie Storable o.ä. zu nehmen um das als Response zu senden anstatt einen eigenen Serializer zu implementieren. Was wir brauchen, ist ein Deserializer in JavaScript, wo obenstehende Struktur deserialisiert in einer Datenstruktur im DOM landet.
Damit können auch neue HTML5-Elemete wie audio, video mit Daten betankt werden, ich habe das mit einem proprietären Serializer/Deserializer getestet und das funktioniert einwandfrei. Nichts produktives, nichts aufregendes und nur Hobby.
Interessant wirds das erst, wenn JS im DOM mit einer Binary zurechtkommt, die mit Perl/serverseitig per Storable::freeze oder Sereal o.ä. erzeugt wird. Sozusagen Perl-Standards in den Browser hinein verlängern.
Wenn ich in den nächsten Tagen dazu komme, gehe ich das mit Storable und o.g. Hash of Hashes an. Mein Verständnis für c muss ich sehr auffrischen, ist schon ne Weile her ;)
Der Gewinn gegnüber XML, JSON, YAML u.a. liegt in einem kleineren Bandbreitenbedarf und einem besserern Verhältnis zwischen Nutzdaten/Verpackung, was für mobile Endgeräte auch in Zukunft eine Rolle spielen dürfte.
Genauso möglich: PHP serialize('Quellcode liegt offen'). Na, vielleicht mach ich das als Erstes, aber Perl ist mir letztendlich lieber ;)
Edit: PHP.serialize() ist irreführend, das ist zwar binary-safe aber zeichenorientiert und nicht im Sinne einer Sequenz nach Niklaus Wirth; was aber nicht heißen soll, dass ich jetzt auf Pascal umsteige ;)
Last edited: 2014-02-08 09:21:26 +0100 (CET)