After spending the day finishing out cross-browser EventSource support in the form of jQuery.EventSource.js, then wrapping up with a commit of 55 new unit tests, I finally left the Bocoup Loft for the day around 8 o’clock… But as most developers know, no matter how hard you try, you just can’t leave this kind of work at the office. On the short ride home I had some time to reflect on the developments of modern browsers and how exciting things like Workers, SharedWorkers and EventSource are…
… And that’s when it occurred to me… Could it be possible that when the Chromium crew implemented the EventSource API, that they extended the interface across processes so that both the renderer and worker processes had access to the constructor?
After taking Alli the Dog for a quick walk, I spun together this demo…
Some HTML to facilitate running the test in a browser:
The contents of renderer.js; this will create the worker object and then send a quick dummy message out to it.
The contents of worker.js; this will receive the dummy message, declare a new EventSource and start listening to it.
The contents of event-source.php; this simply sends a modified text/event-stream header then echoes a small json fragment, prepended with the ‘data; ‘ tag:
… So what was the result? While I wrote this, I ran the demo in another tab and at this moment 355 EventSource messages were received by the Worker, which in turn sent 355 messages back to the renderer (client/browser) which then logged them to the javascript console.
It’s not much, but it’s proof that it can be done - bear in mind that only the WebKit browsers support EventSource, therefore this will only work in either Chrome 5+ or Safari 5+.
Download the demo files from Github
This entry was posted by (@rwaldron) on August 26, 2010 in EventSource, JavaScript, V8, Web Workers and WebKit.
Comments