This is mighty awesome. I’ve put together some test demos, to run them you’ll first need to get this Chromium build:
Then download these:
For something (only slightly) more involved
Both examples can be found here:
http://code.bocoup.com/event-source/event-source-1.html
http://code.bocoup.com/event-source/event-source-2.html
They have only been tested in a Chromium nightly and definitely don’t work in FireFox. Be sure to have the javascript console open when running these in order to see the output.
EDIT
In the comments below, there is some interesting info about how this is actually implemented, most notably the comment left by obigid and my reply to them.
More Findings, May 27, 2010
In case you’re wondering what kind of HTTP request is being made, it is a GET request. Here are the passing tests:
http://gist.github.com/415836
http://gist.github.com/gists/415836/download
8 Comments
I don’t think this is “pushing” events from the server. Based on this comment:
// despite not having the while(true){}
// this seems to repeat pushing messages to the client
I guess Chrome is polling the server over and over again, so this is simply a ‘shortcut’ for something every browser with XHR support can do.
You don’t need a nightly build, both examples work in Chrome 6.0.408.1 dev!
Awesome!
Glad you mentioned this… I came to the same conclusion after discovering that it would repeatedly fire the MessageEvent whether or not the PHP was on a loop. So basically, it’s faking server push by polling natively.
Thanks! I had stumbled upon this when I was investigating Native Client and had downloaded the Chromium 6 builds that were listed in their “Getting Started” docs, so to play it safe, I only recommended the build I was certain it would work in – thanks for the info!
I have two questsions. If you will add while(true) { sleep(10); … } at server side will it still work? Will other connection (AJAX) to the same server not block? Will this be asynchronously piped back to JS on the fly? Can we easly have many (50) EventSources and still this will be efficient? Can we have EventSource to other domains? Is Cross-Origin mechanisms working then?
Sorry for questsion, but I don’t have Chrome here working. And I think this information will be usefull for everyone.
Ah and last think, I think you should first detect if EventSource can be created (using IF or TRY/CATCH), so will detect webbrowsers which doesn’t support it).
Isn’t it a problem that they are polling the server? I mean, what happens if the server really were doing what it was supposed to do? Possible problems:
1. Excess traffic
2. Events sent from the server (not in response to the invisible polling) go where?
The standard definitely says “push”. Should we assume that Chrome’s current behavior will change to match the standard some time in the future?
I don’t think this is “pushing” events from the server. Based on this comment:
// despite not having the while(true){}
// this seems to repeat pushing messages to the client
I guess Chrome is polling the server over and over again, so this is simply a ‘shortcut’ for something every browser with XHR support can do.
2 Trackbacks
[...] he uncovers new support for the EventSource API that allows for simple server push of DOM events as shown in this simple [...]
[...] This post was mentioned on Twitter by rick waldron and kernowsoul, Fabio Caseri. Fabio Caseri said: Chrome 6: Server Push Events with new EventSource() http://bit.ly/akZgl8 [...]