How does Gmail do comet on Opera?

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).

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.

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.

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.

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.