Monday 24 December 2012

HTML5 SSE

AS of about 4pm this afternoon I knew nothing about HTML5 specific code, nor the SSE (Server Sent Events) mechanisms.  I was blissfully living in the past where you had to do client pull to get data onto a browser.

But at 4pm, I started looking for a piece of code, the reason I was looking at this code was work... Remember that project I mentioned I had delivered, well that project was to convey some data from a source machine to a target over TCP/IP, the conduit being a Raspberry Pi, but the target machine was going to be a database, from whence there was to be a website doing alerts straight onto the screen...

This I was all shown before I left work, this was a big deal, my project had taken its time to arrive, this other chap with the web stuff had started before me and was delivering a demo of these alerts on screen from my newly finished feed... He had made a big whoo-haaa about how much work he had done for this... Big deal, the manager was wowing it up and lapping  up the progress.

So, this peaked my interest, so I wanted to see how from basically a web server I could get an alert onto a screen from such a feed... so... Imagining I had the same feed, to a database and then a website... I wanted to see a value go into the database and go out onto the screen...

I had imagined needing some javascript loop on the client to make it refresh some iframe or load values into hidden elements and then transpose them up the DOM into some visual controls.

But, actually... All I needed was SSE, and I had this working, showing me an alert (at least in the javascript console) in about 10 minutes.

<HTML>
<HEAD>
<SCRIPT language="javascript">
var source = null;

function LoadPage ()
{
    source = new EventSource('update.php');
    source.addEventListener ("message", Tick, false);
}

function Tick (event)
{
    console.log (event.data);
}
</SCRIPT>
</HEAD>
<BODY onload="LoadPage()">
</BODY>
</HTML>

Right, so this page opens something in HTML5 an event source and on each time the server pushes an event of the type "message" the "Tick" function is called, and the "event.data" is the string of raw information from the server.  So I want to create this "update.php" page which will send the event:

<?php
header("Content-Type: text/event-stream\n\n");
header("Cache-Control: no-cache");

echo "data: " . "HelloWorld" . PHP_EOL;
echo PHP_EOL;

do_flush();
flush();
?>

And this is "update.php", you see we manipulate the header returns to we're streaming events back, and then we send one event the "data:" line is the event with the string "HelloWorld", but we could stream json, or XML or whatever we like there and our "Tick" function on the web page will handle it.

What the browser (at least what Chrome) then does is it'll poll around again all on its own and you get this PHP page reloaded after 3 seconds, when the PHP page loads, with this code example in the JavaScript console (opened with F12 in Chrome) you see it log "HelloWorld", and then count following events of that type.

I did this in about 10 minutes, and that included copying the examples from another website... I can see great potential for this for the project at work, I can see a dozen or more messages I already transmit being hoisted out of the target server and streamed to a browser with a HTML5 canvas displaying a live read out of the source machine status, and I can see that being a real killer application for the project.

But you know what, the guy doing it has had months to work on this, and he's only just got this eventing stream thing working, something that took me about 10 minutes has taken him days, if not weeks, of his project.  Either he's shirking his time, or he's simply not doing the work.

1 comment:

  1. Those of you interested in this post might want to look at my first of 2013...

    ReplyDelete