Comet revisited

[heidtmare]

I know it's been brought up before, but I feel that Ext could benefit from a Comet helper.
This helper could create a hidden frame, make the initial request, watch for population changes, and put the content fragments into the desired final location.

That would be a sweet little piece of Ext goodness.
Anybody agree?

[kalebwalton]

I agree - it would be great to have some sort of push implementation supported by Ext.

[RutgerB]

It would indeed be great to have a Comet helper in extjs

[JorisA]

Maybe I dont really get the concept, but why not disable timeout and make an Ajax call. onSuccess handle the recieved data.

[Ronaldo]

Maybe I dont really get the concept, but why not disable timeout and make an Ajax call. onSuccess handle the recieved data.

The concept of comet is that every browser client should not poll for data, which is (theroretically?) less scalable, but the server should push (changed) data to clients viewing that data. Thus, you'll only need to transfer data when it's changed.

Just my 2 cents

[cluettr]

I like the push concept and I was hopeful that a solid open-source and/or freely available framework would be available by now. While Dojo does have comet capabilities its poorly documented and I have yet to see a good example. I, like most, need examples to get off the ground.

[Animal]

I use DWR's "reverse Ajax". It polls the server on a configurable timer. I have it polling every 30 seconds. Based on Java as a back end.

[k2pts]

The basic idea is the following:

http.onreadystatechange = function() {
    if (http.readyState == 3) {
      getData();
    } else if (http.readyState == 4) {
      // disconnected/completed
      if (http.status == 200) {
      // do something
      } else {
       // something wrong in http request
      }
    }
  }

The above would work on Firefox provided that:

* the connection remains open... it is also interesting/challenging how you can keep the connection open without consuming all resources on your server (e.g. release the thread serving the initial request and you use a master thread to push data to the subscribed connections)

* you have some way to parse chunked response data, for example:

 
  response = http.responseText.substring(http_last);
  if (response.match(/\}[\n\t ]+$/)) {
        response_chunks=response.split('\t');
        for (var j=0;j<response_chunks.length-1;j++) {
             // do something
        }
 }
  http_last = http.responseText.length;

IE (earlier versions for sure, don't know about IE7) needs some extra work as, IIRC, it won't allow you to access responseText while readyState==3. There is an alternative/workaround using iframes and simulating the aforementioned behaviour.

[Troy Wolf]

I frequently revisit the idea of push communications in the web environment. For those that may not understand the concept...consider a web page that displays the score of a soccer game in progress. You visit the page, and every 30 seconds, the score numbers automatically update to reflect the current score. The page would probably use "AJAX" to do this. What if you want the page to update "immediately" when a goal is scored? How can you have the server push this new information to the clients? Today, most people solve this by having the client browser update at a higher frequency. That is, update every 5 seconds instead of 30.

The downside is that now you have the browsers hitting the server every 5 seconds even though there may not be any new information. The browser has to keep asking "anything new?". It would seem that a way for the server to push new information when and only when it is available would be more efficient.

However, this would require an open socket between the browser client and the server. In reality, the overhead of having every browser connection maintain an open socket is less scalable than having all those browsers making tiny requests every 5 seconds.

So unless I am misunderstanding the technology (very possible), in a mass-public web app, push technology would not scale very well.

Like many, when I'm in doubt about a best methodology, I look to Google---how do they do it? I figure if a method is good enough for Google, it's good enough for me.

[Wolfgang]

Interesting.
Flash and AIR do provide sockets based on TCP, which maintain a connection and won't scale.
However they work very well in a minor environment.

Do you know any browser plugin that supports listening UDP sockets? Since UDP is connectionless it would scale much better.

Regards

Wolfgang