I'm sorry guys but what is exactly "server-push" you are talking about? There can't be such thing as server-push in a pure html/ javascript world because http doesn't implement it. Applets (java, active-x, flash etc) can do that. But in the GWT world it's still the old good polling. Even if it's a long-hold polling request as comet uses it, it's still a poll request.
On 17 Apr., 10:02, Tony Strauss <[email protected]> wrote: > I think that I'm going to have to take back a lot of my prior > message. It seems like the Live HTTP headers extension does not > correctly order hanging requests. The extension always seems to place > a response after a request if they occur close to one another; either > that, or I am misreading the output completely. I got suspicious > after studying the requests made by Google Chat, which must use server > push. In any case, I found an extension that shows what is going on > more clearly: Tamper Data. > > https://addons.mozilla.org/en-US/firefox/addon/966 > > Tamper Data shows that GMail *is* using hanging get requests; the get > requests last about 30 seconds. I still see a 30 second lag for email > reception, however, which means that Google is buffering emails and > not pushing them to the client when they arrive. I think that the > reason for GMail's use of server push is the necessity of supporting > Google Talk. It seems like Google Talk and GMail share a hanging get > request; receiving a chat message seems to push a new message > instantly (no waiting for the normal timeout after 30 seconds). > > This is just speculation, but perhaps before Google Talk, GMail polled > for new messages every 30 seconds. When it became necessary to > support Google Talk, Google switched to server push (for both > services, in order to minimize the number of browser connections that > would be tied up) but did not push messages any more quickly than they > would have before (presumably in order to keep the number of requests > the same, leaving aside the extra requests to support Google Talk). > > Tony > -- > Tony Strauss > Designing Patterns, > LLChttp://www.designingpatterns.comhttp://blogs.designingpatterns.com > > On Apr 17, 3:03 am, Tony Strauss <[email protected]> > wrote: > > > I'm going to guess thatGMailpolls. > > > I took a look at the requests thatGMailmakes with Firefox's Live > > HTTP headers when not actively interacting withGMail. It seems to: > > 1.) Make one GET request roughly once every 30 seconds. > > 2.) Make one POST request roughly once every 30 seconds (although at > > one point during part of my monitoring, this seemed to be happening > > once every minute). > > > It appears that both requests get responded to immediately (the > > response appears right after the request), which would seem to > > indicate thatGMailpolls (no hanging requests). > > > As an experiment, I sent an email from anothergmailaccount and this > > only appeared when the 30 seconds between GET requests were up, which > > also makes me think thatGMailpolls. IfGMailwere using server > > push, I would have expected to see the new message immediately > > (although Google also could wait a small amount of time before pushing > > down a new message, in order to send down several new messages at > > once...). > > > Polling would be acceptable forGMailfrom a latency point of view > > because most people probably do not need to see a message at the very > > instant it is sent. > > > Tony > > -- > > Tony Strauss > > Designing Patterns, > > LLChttp://www.designingpatterns.comhttp://blogs.designingpatterns.com > > > On Apr 17, 2:05 am, Vitali Lovich <[email protected]> wrote: > > > > Naw - the small connection limit (usually two) is per page. I forget > > > how much IE defaults to, but Firefox allows up to something like 32 > > > simultaneous connections. So push would still be an option. > > > > On Thu, Apr 16, 2009 at 6:39 PM, Arthur Kalmenson <[email protected]> > > > wrote: > > > > > I'd venture to guess that they're using polling because I think you > > > > can have as manyGmailtabs open as you want. If it used push, you'd > > > > run out of connections and that would be nasty. > > > > > -- > > > > Arthur Kalmenson > > > > > On Thu, Apr 16, 2009 at 6:19 PM, Vitali Lovich <[email protected]> > > > > wrote: > > > >> Out of curiosity do you know how they get new e-mails to appear in the > > > >> web > > > >> UI? Is it AJAX push or do they just do a regular poll every x seconds? > > > > >> If it's AJAX push approach, I wonder if there's any scalability issues > > > >> with > > > >> maintaining so many open TCP connections & if they just solve it by > > > >> throwing > > > >> hardware at the problem until it goes away, or if they do some kind of > > > >> tricks as well to minimize the resource load of connections that are > > > >> just > > > >> waiting for data on the server. > > > > >> I'm guessing that load balancing would occur when the AJAX call is > > > >> established due to the previous call timing out or returning data > > > >> (probably > > > >> live migration of connections would be far too complicated & overkill). > > > > >> On Thu, Apr 16, 2009 at 4:31 PM, Jason Essington > > > >> <[email protected]> > > > >> wrote: > > > > >>> SinceGmailpredatesGWTby several years, it wasn't written inGWT... > > > > >>> As for rich text widgets, they all use the browser's built in HTML > > > >>> editing capabilities, making them a bit finicky. > > > > >>> -jason > > > > >>> On Apr 16, 2009, at 1:34 PM, Vitali Lovich wrote: > > > > >>> > Does anyone know ifgmailusesGWTfor its widgets and whatnot? > > > >>> > Partially curiosity & partially I regularly have problems with the > > > >>> > rich editing widget not displaying the cursor properly under > > > >>> > Firefox. > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~----------~----~----~----~------~----~------~--~---
