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:
https://gist.github.com/415116
client.html
<script src="event-source.js"></script>;
event-source.js
document.addEventListener('DOMContentLoaded', function () {
var eventSrc = new EventSource('events.php');
eventSrc.addEventListener('open', function (event) {
console.log(event.type);
});
eventSrc.addEventListener('message', function (event) {
console.log(event.type);
console.log(event.data);
});
}, false);
events.php
<?php
header("Content-Type: text/event-stream\n\n");
// despite not having the while(true){}
// this seems to repeat pushing messages to the client
echo 'data: ' . time() . "\n";
?>
For something (only slightly) more involved
https://gist.github.com/415294
event-source-2.html
<script src="event-source-2.js"></script>
event-source-2.js
document.addEventListener('DOMContentLoaded', function () {
var eventSrc = new EventSource('event-source-2.php');
console.group('EventSource Created');
console.dir( eventSrc );
console.groupEnd();
eventSrc.addEventListener('open', function (event) {
console.time('Time Elapsed between open and message');
console.log(event.type);
});
eventSrc.addEventListener('message', function (event) {
console.timeEnd('Time Elapsed between open and message');
console.log(event);
console.dir( JSON.parse(event.data) );
});
}, false);
event-source-2.php
<?php
header("Content-Type: text/event-stream\n\n");
// despite not having the while(true){}
// this seems to repeat pushing messages to the client
echo 'data: ' . json_encode(
array(
0 => array(
'time' => time(),
'message' => 'Some kind of foo'
),
1 => array(
'time' => time(),
'message' => 'Some kind of quux'
)
)
) . "\n";
?>
Both examples can be found here:http://code.bocoup.com/event-source/event-source-1.htmlhttp://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:
https://gist.github.com/415836https://gist.github.com/gists/415836/download
Comments
We moved off of Disqus for data privacy and consent concerns, and are currently searching for a new commenting tool.
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.
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.
You don’t need a nightly build, both examples work in Chrome 6.0.408.1 dev!
Awesome!
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.
Emily is right, this is \”not\” a pushing events when you
//despite not having the while(true){} …
//…
..and need not to \”guess\” of polling the server over and over again.
You can make a little test.
Add another event listener of your code like this:
eventSrc.addEventListener(\”error\”,function(e){
console.log(\”server disconnected now\”);
});
then will see \”server disconnected now\” every about 3 seconds.
so, it’s mean you just do things like sending a ajax request to your server….again and again…