hotti: Objekte per Ajax mit Daten betanken

hi,

ausgehend davon, dass es hierzu vermutlich noch einige Unklarheiten ob der Realisierung solcher Vorhaben gibt, schreibe ich mal was dazu. Die eigentliche Schwachstellen liegen nicht etwa in HTTP oder Ajax an sich, sondern es sind die Browser. Es geht damit los, dass ein URL scheme nach rfc 2397 nicht von jedem unterstützt wird, also sowas:

img src="data:image/gif;binary,<DATA>

das können einige Browser wie FF, Moz und Op allenfalls, wenn das Dateichen als hexmap %00%AA...%FF vorliegt und damit wird eine Datei dreimal so groß wie die bin (aus einem byte werden 3 Zeichen).

Mit Base64 sieht das scheme so aus:

img src="data:image/gif;base64,<DATA>

(IE ab v8, Moz, FF, Op OK)

und damit wird eine bin um etwa 30% größer, dazu kommt sicher eine gewisse CPU-Last um das wieder in eine bin umzurechnen zum darstellen.

Fazit: Wenn die Browser o.g. scheme mit Parameter binary verstehen würden, gäbe es weniger Overkill.

Die zweite Sache liegt auch im Verhalten der Browser begründet: Wenn große Datemmengen anstehen, verteile ich die auf mehrere Requests, und da verhalten sich die Browser sehr unterschiedlich (danke Struppi).

Ich habe hier ein Script, da werden über 30 Images (zusammen ca 1.5 MB, bischen Text ist auch dabei) angefordert und dazu asynchron ebensoviele Requests in einer for-Schleife rausgefeuert, Fazit: Opera macht das vorzüglich, nach einer Sekunde ist die Sache erledigt. Moz und FF bremsen sich da offensichtlich aus, aber der Vorzug einer asynchronen Übertragung ist ja der, dass ich nicht warten muss, bis _alles_ angekommen ist, ich kann beispielsweise schon nach der Ankunft des ersten Fotos mit einer Dia-Show beginnen (Preload).

Das wären so die technischen Geschichten, der Programmieraufwand ist vergleichsweise nicht nur gering, sondern sehr gering. Also wenn Ihr wollt, könnt Ich Euch das mal anschauen:

Mallorca

Viele Grüße,
Rolf

  1. Hi,

    Fazit: Wenn die Browser o.g. scheme mit Parameter binary verstehen würden, gäbe es weniger Overkill.

    Noch weniger Overkill wäre es, wenn du die Browser ganz normale Bildressourcen über HTTP laden ließest.

    MfG ChrisB

    --
    “Whoever best describes the problem is the person most likely to solve the problem.” [Dan Roam]
  2. Hallo hotti!

    Mallorca

    Sei so nett, kauf Dir ein ordentliches Grafikprogramm oder lern den Unterschied zwischen Resizen und Resamplen oder mit Schärfen umzugehen. Deine Bilder sind echt... miserabel!

    Viele Grüße aus Frankfurt/Main,
    Patrick

    --
    _ - jenseits vom delirium - _

       Diblom   [link:hatehtehpehdoppelpunktslashslashwehwehwehpunktatomicminuseggspunktcomslash]
    Achtung Agentur! | Nichts ist unmöglich? Doch! | Heute schon gegökt?
  3. Moin!

    ausgehend davon, dass es hierzu vermutlich noch einige Unklarheiten ob der Realisierung solcher Vorhaben gibt, schreibe ich mal was dazu. Die eigentliche Schwachstellen liegen nicht etwa in HTTP oder Ajax an sich, sondern es sind die Browser. Es geht damit los, dass ein URL scheme nach rfc 2397 nicht von jedem unterstützt wird, also sowas:

    img src="data:image/gif;binary,<DATA>

    Wozu auch, schließlich kann man als src-Parameter auch eine URL angeben, die der Browser lädt - direkt, platzsparend, ohne irgendwelchen Overhead.

    Fazit: Wenn die Browser o.g. scheme mit Parameter binary verstehen würden, gäbe es weniger Overkill.

    Deine Lösung ist der Overkill. Wenn man Bilder vom Server laden will, dann tut man dies am einfachsten dadurch, dass man diese durch Angabe ihrer URL lädt.

    Das läuft sogar noch performanter, als mit Ajax, weil pro Domain bis zu vier Bilder parallel geladen werden, ohne dass man sich mit Javascript explizit drum kümmern muss. Die Anzahl an parallelen Ajax-Requests ist hingegen durchaus begrenzter - und kann zudem sinnvoll auch erst nach dem Fertigladen der eigentlichen Seite stattfinden.

    Ich frage mich also, was für ein Problem du hier eigentlich lösen willst...

    - Sven Rautenberg