hotti: Mehrere Content-Types zusammen in einer Ajax-Response

Nur als kleine Vorab-Info, heute und die nächsten Tage komme ich nicht dazu, einen Artikel+Demo zu schreiben...

Also: Nach dem Studium der neuen Features, HTML5 FF usw. werde ich Euch demnächst zeigen, wie eine (proprietäre) Multipart-Message in einer Ajax-Response übertragen und einzelne Komponenten in einem neuen Browserfenster ausgegeben werden können, nachdem die Response im DOM angekommen ist.

Die einzelnen Komponenten können einen beliebigen Content-Type haben, z.B. image/gif, application/octet-stream, text/plain, text/html, application/pdf usw. und alles zusammen in einer einzigen Response. Neue Features ermöglichen es, diese Einzelkomponenten als reine Binary zu übertragen, also nicht etwa als base64/JSON/XML, und ich ermögliche es, dass alles zusammen übertragen wird, eben als Multipart-Content.

Eine kleine Demo habe ich schon fertig, für den Artikel brauche ich noch ein bischen...

Bis demnächst, bin die Tage unterwegs,
Horst

  1. hi,

    Eine kleine Demo habe ich schon fertig, für den Artikel brauche ich noch ein bischen...

    Hier ist alles zusammen

    Doch noch heute geschafft, aber das Thema lässt mir einfach keine Ruhe ;)

    Es streift auch die Aufgabenstellung, etwa ein neues Fenster mit nur einer Grafik oder PDF... öffnen zu wollen (Content-Type: egal/scheis-egal).

    Was sich derzeit im MDN tut, ist gewaltig!

    Grafik nach RFC2397: Image.src=url (url => blob:dfa6b650-1db4-46bc-8439-2ed02fc3fdc2)

    Ha, von wegen Base64. Browser können Binary, das konnten die schon immer. Neu ist das Blob-Objekt und damit können URLs erstellt werden, die RFC-gerecht nur ASCII sein dürfen. Dazu wird browserintern auf einen Token gemappt, siehe oben. Dieser Token verweist intern auf die reine Binary (im DOM eine eindeutige Kennung).

    Also: window.open('blob:dfa6b650-1db4-46bc-8439-2ed02fc3fdc2') geht natürlich auch. Und sicher auch andere Elemente, die einen url benötigen (Audio, Video...).

    Schönes Wochenende!
    Horst

    1. Meine Herren!

      Doch noch heute geschafft, aber das Thema lässt mir einfach keine Ruhe ;)

      Da musst du nochmal ran:

      Meine Fehlerkonsole meckert:

      Refused to set unsafe header "Content-length"  
      Refused to set unsafe header "Connection"  
      Uncaught TypeError: Constructor DataView requires 'new'
      
      --
      “All right, then, I'll go to hell.”
  2. Meine Herren!

    So ganz habe ich deinen Artikel wieder nicht verstanden. Ein paar Anwendungsbeispiele oder Diagramme könnten vermutlich Wunder bewirken.

    Hier hab ich was für dich:

    Protocol Buffers
    SPDY

    Obendrauf sind diese Lösungen frei und quelloffen.

    --
    “All right, then, I'll go to hell.”
    1. Meine Herren!

      Hier hab ich was für dich:

      BSON nicht zu vergessen.

      --
      “All right, then, I'll go to hell.”
    2. hi,

      So ganz habe ich deinen Artikel wieder nicht verstanden. Ein paar Anwendungsbeispiele oder Diagramme könnten vermutlich Wunder bewirken.

      Mein Serializer, einfacher gehts nicht: Von einem Array werden immer abwechselnd die Längenangabe und dann das Element in die Bin geschrieben. Wobei: Die Längenangabe liegt IMMER auf einer FIXen Anzahl an Bytes, z.B. sind das IMMER 4 Byte. Nur so kriegste die Daten da wieder unzerknittert raus:

      while(read(4 Byte)){
          DataView Objekt für den Integer
          Der Integer (z.b. 21) ist die Länge der nächsten zu lesenden Bytes
          read(21 Byte) hiermit haste den Wert selbst
          und dann wiederholt sich das bis der Buffer aufgefressen ist
      }

      Isses ein assoziatives Array, gehören die Werte paarweise zusammen, die Bin bleibt dieselbe, nur der Algorithmus ist anders.

      Es gibt immer Gründe für eigene Entwicklungen. Danke für Deinen Fehlerhinweis, ist erledigt. Mein FF ist v26.0 da funktioniert das alles. Ist ja nur ne Demo und nix Produktives. Und alles zusammen auch nüschd Neues. Nur insofern, als dass es so erschreckend einfach ist und eine Multipart-Message mit den Objekten DataView und Blob auskommt.

      Horst

      PS: Mein Serializer läuft schon seit Jahren serverseitig.

      1. Ein _wirklich_ _gut_ _gemeinter_ Hinweis:

        Bei uns in der Firma suchen wir Leute, die fit in Perl sind. Deine örtliche Entfernung wäre evtl. sogar tragbar.

        Da Du aber so dermaßen darauf fixiert bist, das Rad immer wieder aufs Neue zu erfinden und manchmal geradezu widerlich Deine konfus wirkenden "Erfindungen" hier propragierst: keine Chance.

        Du solltest Dir vielleicht mal überlegen, ob Dich das letztlich weiter bringt. Zumindest falls Du wirklich auf der Suche nach bezahlter Arbeit bist.

        1. Für mich gab es schon immer Gründe, Alternativen zu JSON, XML und Base64 zu entwickeln.

          Heute gibt es sogar einen wirtschaflichen Grund: Die fortschreitende Verbreitung mobiler Endgeräte. Hier haben wir geringe Bandbreiten, da zählt jedes Byte und jeder Request, der eingespart werden kann.

          Schöne Grüße!

          1. Heute gibt es sogar einen wirtschaflichen Grund: Die fortschreitende Verbreitung mobiler Endgeräte. Hier haben wir geringe Bandbreiten, da zählt jedes Byte und jeder Request, der eingespart werden kann.

            Stimmt! Vielleicht findest Du ja die ultimative Lösung für alle Probleme, lässt Sie Dir patentieren und schreibst in einigen Jahren aus Deiner Finca auf Malle: perfekt!

            Falls Du aber etwas weniger optimistisch ob Deines baligen, bombastischen, Erfolges bist und einfach produktive Arbeit leisten willst, bist du aktuell komplett inkompatibel zum Tagesgeschäft.

            Deine Beharrlichkeit ist bewundernswert, aber die Diskrepanz aus deinem Anspruch zu deinen hier präsentierten Ergebnissen lässt mich an erster Variante zweifeln.

            Du musst selber einschätzen, welcher Weg für Dich erfolgsversprechender ist.

          2. Meine Herren!

            Heute gibt es sogar einen wirtschaflichen Grund: Die fortschreitende Verbreitung mobiler Endgeräte. Hier haben wir geringe Bandbreiten, da zählt jedes Byte und jeder Request, der eingespart werden kann.

            Das meint Mitleser vermutlich damit, dass du ständig das Rad neu erfindest. Eine bessere Recherche im Voraus hätte dich vielleicht auf diese Seite gestoßen: http://en.wikipedia.org/wiki/Comparison_of_data_serialization_formats

            Ich habe deinen Artikel nochmal und nochmal gelesen bis ich verstanden habe und kann leider nichts Innovatives oder Wegweisendes darin finden.

            Ich an der deiner Stelle würde mich nicht an deine Lösung klammern. Es hat sicher Spaß gemacht und auch dein Verständnis von Serialisierungs-Verfahren verbessert, aber für den Produktiv-Einsatz würde ich auf etwas Erprobtes setzen, was sich schon etabliert hat und was schon für zahlreiche Systeme implementiert ist.

            Übrigens ist deine Deserializer ziemlicher Spaghetti-Code: Du interpretierst die Daten on-the-fly anstatt sie erst wieder in einen Hash zurück zu verwandeln, mit dem man besser arbeiten kann. Das wäre ein konkreter Verbesserungsvorschlag von mir.

            --
            “All right, then, I'll go to hell.”
    3. Hallo,

      Hier hab ich was für dich:

      Protocol Buffers
      SPDY

      Da hänge ich mal einen schönen Artikel über HTTP 2 dran.

      Mathias