how does the channel api work under the hood?

[vega]

hi everyone
i dont think that it makes any difference in which language (java, python, go) the server is implemented, so i post in this forum and not in the java forum, maybe im wrong, but i hope thats not the case :)

i noticed that my client page, which uses the channel api to get information from the server makes every +-28 seconds a http get request to a google server.
okay... so the channel api works via long polling....
wait... didnt the documantation say it works without the use of any polling?!

"The Channel API creates a persistent connection between your application and Google servers, allowing your application to send messages to JavaScript clients in real time without the use of polling."

first i thought that this would be a backup mechanism for old browser versions which doesnt support html5 sockets.
so i updated my firefox to the newest version and it still used long polling.... after a bit of searching around i found that firefox needs extra mozilla websockets instead of websockets.... whatever...
so i tried the newest Opera version.... where it also uses long polling...

and by the way, why does it need a .js file which is on another server which is probably blocked by most of the company firewalls cause of talkactive being a chat programm?

so im kinda curious, is there somewhere an explanation on how the channel api works "under the hood"?

[Moishe]

>"The Channel API creates a persistent connection between your application >and Google servers, allowing your application to send messages to JavaScript 
>clients in real time without the use of polling." 

The Channel API uses the same mechanism that Gmail chat, Google+
notifications, etc. use to deliver messages to javascript clients.
Currently the most widely-available way to do this is by long-polling
rather than by websockets. So, the _implementation_ uses long-polling,
but that should be opaque to apps -- your app doesn't need to
implement all the plumbing to handle any sort of polling.

The .js file lives on another server because that server is
responsible for the long-polling plumbing; it's mostly a detail to
facilitate rollout. Whether or not the .js is blocked is almost
irrelevant, since the actual long-poll goes to the same server and if
that's blocked nothing will work. There is a feature request on our
issue tracker (http://code.google.com/p/googleappengine/issues/detail?
id=4764) to move these off of the talkgadget domain.

Hope that sheds some light-

-Moishe