How does Gmail do comet on Opera?

Question

I would like to know how Gmail (or anyone else) does comet on Opera.

Here is what I know so far from my experiments.

1. It doesn't use the event-source tag which is broken in Opera 10.51.
2. It doesn't use iframe which displays a spinning throbber and a busy mouse cursor.
3. It doesn't use responseText on xmlhttprequest when readyState = 3 which is known to be broken on Opera.

I tried seeing how it was done in mibbit and etherpad, and I found that they both use long-polling.

Bounty

The bounty goes to whoever can tell me a method better than "event-source" for Opera comet streaming, or how gmail does streaming (or long-polling if it does that).

Sarsenet

Answer 1

GMail uses BrowserChannel (Docs | Source), which is included in Google's Closure Library.

• @fileoverview Definition of the BrowserChannel class. A BrowserChannel
• simulates a bidirectional socket over HTTP. It is the basis of the
• Gmail Chat IM connections to the server.

Emotion

i.e. closure-library.googlecode.com/svn/docs/… Think what you're actually looking for is around here: closure-library.googlecode.com/svn/docs/… search for pollResponse_ and getNextChunk_ :) – Mechling

Can you be a little more specific? I feel that I've given a generous enough bounty to warrant an answer more than just a link to a giant abstract library. – Sarsenet

Well, I sort of feel that should be left to Jason as he gave the original pointer to Closure and I just went a little bit deeper.. Looking at that source code, it seems to use an async XMLHttpRequest indeed, with a timeout that's responsible for polling the responseText and handle incoming data. Opera doesn't fire several readystatechange events while chunked data is coming in (which Firefox does mostly by a happy accident I think - there is no standard or documentation mandating this implementation as far as I know). So instead of expecting multiple readystatechange events they use timeouts. – Mechling

@hallvors, yes I was addressing Jason. If you leave a more detailed answer I will accept yours unless you feel that Jason deserves the bounty. – Sarsenet

Unfortunately the documentation on BrowserChannel is pretty thin, and I don't have any first-hand experience with it myself, so I can't really say how it solves this particular problem. The best you can do is look at the code and try to work it out. If you don't think I deserve the bounty, I'm fine with that, I was just trying to point you in a helpful direction. – Emotion

There's a sidebar question which seems like it may also be helpful? #2482196 – Emotion

@Jason, I will give you the bounty if your remains the best answer. But if you can improve it some more, I will give you the bounty right away. – Sarsenet

Answer 2

I really don't have any idea on what the answer is. But I know Opera supports server-events : http://my.opera.com/WebApplications/blog/show.dml/438711 . Maybe it's a step towards the anwser? I'm not really sure either, but I think they use it within Opera Unite.

Attendant

No, it doesn't use event-source like I said. Event-source is completely broken in Opera 10.51, and gmail still streams gchat just fine. – Sarsenet

Answer 3

I think that rather cross-browser (including Opera) approach might be to stream data through an Adobe Flash application. Though it would introduce dependence on the Flash plugin and is not very popular because of that.

Comfortable

Answer 4

I am the author of an in progess C++ HTTP server that is compatible with goog.netBrowserChannel. You can find the docs I've written while studying the protocol here:

http://code.google.com/p/libevent-browserchannel-server/wiki/BrowserChannelProtocol

Long story short, BrowserChannel uses forever frames on IE and XHR streaming on all other browsers. The protocol is divided into several phases, the first of which is network testing:

1) test the network to ensure response "streaming" is supported (in other words no buffering proxy exists)
2) check access to a variety of network prefixes (to make sure the network admin has not blocked access to chat)

Then the actual data transmission can start. Data is divided into two channels (forward and back). The back channel is a series of long lived (about 4 mins each) requests used for the server to "stream" content to the client. To do so HTTP chunked encoding is used. The client does it's best to make sure that one backchannel is always open. The server will close it about every 4 mins after which the client will open a new backchannel. The forward channel is used to send data from the client to the server. This pushing of data is done as necessary.

Hymnist