Ankündigung

Einklappen
Keine Ankündigung bisher.

Polling oder gibt es eine bessere Variante?

Einklappen
X
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

  • #16
    Ja genau deswegen ja, wenn immer ein neues kommt dann will er 1. nicht cachen 2. wird es immer komplett neu übertragen, 2 Punkte die nicht für Polling über normales HTTP sprechen.

    Kommentar


    • #17
      Ich sehe den sinn der Sache nicht. Dann würdest Du Sockets für eine Sache belegen, für die es normalerweise eine bewährte Vorgehensweise gibt.

      Aber die Diskussion ist ohne den TE eh spekulativ..

      Kommentar


      • #18
        tarian, sag doch mal wozu und warum. : Ich kann mir höchstens vorstellen, dass du möchtest, dass zu einem bestimmten Serverereignis sofort ein Bild geändert wird. Zum Beispiel eine live Statusanzeige.

        @florian: du meinst base64_encode() ? Und wenn das dann so zwischen dem <img></img> tag steht dann geht das echt? Genial. Gleich mal testen^^.

        Ja so würde das dann funktionieren. Allerdings mit der Einschränkung, dass du in diesem Stream wohl nur das Bild übertragen könntest und keine zusätzlichen JS-Anweisungen. Also könnte man diesen Stream dann nur datu verwenden.

        Kommentar


        • #19
          Wieso du kannst doch beliebige Daten versenden, musst sie halt entsprechen verpacken. Z.B. als JSON String, dann kannst du ein Feld für Befehle nutzen und eines für das Bild.

          Und für die "inline" Bilder schau mal: http://www.websiteoptimization.com/s...inline-images/

          Kommentar


          • #20
            Ja logisch. Mann könnte das dann damit wirklich auseinander parsen. Hab grad net soweit gedacht. Ist nur noch die Sache, dass das dann für jeden Client eine ständige HTTP Verbindung benötigt. Das Problem von den Stream und Polling Techniken is halt, dass die Verbindungen von Zeit zu Zeit neu etabliert werden müssen. Und bei vielen gleichzeitigen Verbindungen kann es passieren, dass dann dazwischen große Übertragungslücken auftreten. Daher konnte ich zum Beispiel für mein kleines Game auch keine Echtzeitkollision einbauen sondern musste diese immer vorhersagen. Das funktioniert zwar aber schränkt natürlich die Sache auch massiv ein. Übertragen auf die Sache mit den Bildern, würde das bedeuten, dass diese die meiste Zeit 'live' sind. Aber eben nicht die ganze Zeit. Was evtl. dann zur Folge hat, dass man JS und HTTP dafür vergessen kann.

            Kommentar


            • #21
              Zitat von Geryon Beitrag anzeigen
              [...] HTTP Verbindung offen gehalten wird und der Server je nach Ereignis neue Daten an den Browser sendet. Der Nachteil is halt, dass du damit in der Tat kein Bild übertragen kannst.
              Das kannst du so nicht sagen, solches HTTP Streaming wird häufig bei Livebildern von Webcams eingesetzt, allerdings ohne JavaScript und xhr sondern mittels multipart/x-mixed-replace.
              @fschmengler - @fschmengler - @schmengler
              PHP Blog - Magento Entwicklung - CSS Ribbon Generator

              Kommentar


              • #22
                Ja Fab da hast du recht. Flor1an hat mich in diesem Punkt schon berichtigt. Mir war zwar bekannt, dass sich theoretisch alle Daten und so auch die Daten von Bildern übertragen lassen. Nur nicht, dass man diese dann mittels eines Tags, wie bei <img> tatsächlich auch darstellen kann. Da bin ich nicht mehr auf dem laufenden. Weil meine Frage war halt einfach, wie Javascript dann das ankommende Bild interprätieren soll. Aber das muss es ja garnicht sondern nur an der richtigen Stelle einfügen.

                Interessant währe auch, welche Möglichkeiten neben der base64 injection in einen <img> Tag noch existieren. Evtl. die Darstellung einer mp3 mittels <embed> oder in Plugins wie Flash, die die richtigen Schnittstellen für Javascript bereitstellen?

                Ich kenne das bereits von dem mächtigen O3D Plugin von Google, womit via Javascript ganze 3D Welten geladen, modeliert und online 3D Spiele gestaltet werden können. Auch hier gibt es die Möglichkeit zum Beispiel die URL zu einem 3D Modell anzugeben, welches dann geladen wird. Aber jetzt, wo ich weiß, dass das evtl. auch andersherum funktioniert kann man sich dabei sicher einige Requests ersparen. Besonders, wenn man auf Grund von Streaming eh ständig Daten überträgt.

                Ich habe bisher immer per Ajax / Json usw. URLs übertragen, welche der Browser dann nachgeladen hat. Sicher lassen sich mit dem base64 so, wenn Caching nicht benötigt wird, einige Requests sparen.

                Find ich jetzt echt cool^^

                Kommentar


                • #23
                  Oh da schaut man einen Abend nicht hier rein und ihr schreibt 3 Seiten

                  Folgendes: Wir nutzen im Unternehmen ein externes Programm in dem gewisse Daten zu Bildern gespeichert sind. Diese Bilder sollen einsehbar sein. Wenn man als in dem externen Programm eine Taste drückt, sendet dieses über das Netzwerk einen Query an einen Server, mit Bildpfad/User e.t.c. Dieser hält das Bild vor - Clients schreiben sich in eine Queue ein und holen sich Daten ab falls welche vorhanden sind.

                  Da wir uns im Web2.0 Zeitalter befinden würde ich das gerne Browserfähig machen, da das ständige nachinstallieren o.ä der Anwendung etwas nervt. Hinzu kommt das die derzeitige Applikation auch pollt was im Laufe der Zeit zu gewissen Problemen geführt hat.

                  Ich denke ich muss die Bilder leider als base64 verschicken da es MultiTiffs (ggf. mit Jpeg Kompression) sind und Browser nach meinem derzeitigen Kenntnisstand nicht in der Lage sind diese ordentlich anzuzeigen. Also muss ich entweder auf Server oder Clientseite eine konvertierung vornehmen.

                  Kommentar


                  • #24
                    Ich würde dennoch dahin gehen, die Bilder, wenn, dann auf dem Server zu konvertieren und dann zentral vorzuhalten, statt binäre Daten durch die Gegend zu schicken.

                    Kommentar


                    • #25
                      Ja denke auch das dass die beste Variante ist, besonders weil die Bilder nicht gerade klein sind. Naja mal sehen ob und wie ich es umsetze

                      Kommentar


                      • #26
                        websockets oder, js -> flash -> server (socketverbindung) ein base64 decodiertes bild via socket übertragen und zeichnen.

                        Kommentar

                        Lädt...
                        X