HTML5 and WebSockets

The next revision of HTML (HTML5) goes far beyond updating text styles and markup. It adds support for media playback, adds a new Canvas object for 2-D drawing, and even supports real-time video compositing by using Javascript to generate image frames from real-time data streams.  HTML5 will help make the web even more interactive and alive than it is now with “Web 2.0” apps.

html5-logo_2

I think one of the most interesting additions is the API for WebSockets. The WebSockets API will let Javascript on a web-page open TCP connections to web-services to send and receive data through internet pipes. A WebSocket enabled Javascript program can also modify DOM elements on the page and draw on a Canvas. With these capabilities, the web-page will become more of a full-fledged interactive application with full-duplex communication to one or more hosts.

AJAX technologies already make web pages feel more interactive, but these pages have restricted capabilities: they can only request information from servers and do not asynchronously receive updates from a data source. “Comet” (cleaning product joke intended) is the name given to a new breed of application that implements asynchronous behavior using existing technologies in an ad-hoc manner. The term “Comet” encompasses a variety of techniques that WebSockets will help simplify.

Right now, a developer can implement something like WebSockets using Java or Flash, but both of these have the drawback that they require the user to install a runtime. Some people have been able to implement something like “server-push” using a technique called “forever frames” in which raw Javascript is piped to a browser. In other applications, server-polling suffices to give the illusion of live data.  None of these techniques satisfy the goals of being truly portable and robust with zero-install overhead.

The idea with HTML5 WebSockets is to unify all of these approaches and put the functionality in Javascript. If successful, this new capability will enable real-time live apps that live in the browser. It may even transform web pages from clients into servers. Imagine starting a home-automation server by opening a web page: that’s not the way we think of the browser right now.

Ruby on Rails and Verification

I’ve spent the last few months learning Ruby and using Rails.  Ruby is a dynamic, interpreted language with introspection and a rich syntax for expressing things concisely.  Rails is a web-framework that helps people create industrial-strength web sites.   Both the language and the framework are developed-by and developed-for programmers.  I am very comfortable in this environment!

ruby_on_rails_logo

In a previous life, I worked in Logic Verification for semiconductors.  In the mainstream and over the last decade, Verification evolved from a process in which engineers used simulators to look at waveforms, to self-checking test-benches, to test-generators using randomness to sample a space of possible device behaviors.  It’s interesting to notice how the Rails community has embraced “tests” and “specs” as a fundamental part of the development process.  Good Ruby programmers check-in code with accompanying unit-tests.  And because Ruby has standard packages to express these tests, it is pretty easy to do.  Standard Rails packages extend these ideas to the testing of web sites.  Here, “controller tests” correspond roughly to  “block-level” verification, and “integration tests” correspond rougly to “system-level” verification.

There are other similarities.  The “stimulus” of a logic test is roughly an “HTTP Request” and instead of a “simulator” we’re testing a “web-server.”  Logic “responses” are “web-pages.”  Here is where the comparisons end, however.  Most Web 2.0 web-pages have Javascript in them, and thus the response itself is executable.

In some ways the Rails community is way ahead of the Logic Verification community.  Mutations as a way of debugging the test-bench are standard add-ons to Rails.  Cucumber lets Rails developers write specifications in a high-level language — much clearer than anything I saw in Logic.  The ideas of constrained-random-testing have not yet been embraced in the Rails world, as far as I can tell.  But since there’s a Gem for almost everything in Ruby, I wouldn’t be surprised to see it soon.

D-Link DCS-920 IP-Camera

[See also my more recent post Setting up Sensr to monitor a DCS-920 Network Camera.]

Wow.  Long time, no postings.  I’ve been busy — more on that another time.

Last week I picked up a D-Link DCS-920 wireless IP-Camera on Amazon for $62 (after rebate).  I did not have high hopes for such an affordable camera, but was pleasantly surprised with the installation process and resulting image quality.

dcs-920

The last time I bought one of these types of cameras, the installation process was a little complicated.  This time, it was far easier.  By default, the camera has DHCP enabled, so you plug it into your network using the supplied Ethernet cable and it grabs an address on your network.  I looked at my router status page to see that it had added itself.  Mine also registered itself on my network as “dcs-920” so I could connect to its admin page at http://dcs-920.  Nice!  The default login is “admin” and the password is blank.

The next step was to add the camera to my wireless home network.  Here is how to do that.  Go to the Setup>>Wireless page and click the “Site Survey” button.  This scans the available wireless networks and shows their signal strength.  (My network was right at the top as the strongest.)  Select the network.

Now, the wireless network password has to be set.  This step always seems confusing and error-prone, and I’m not sure why.  Perhaps there are too many security options.  Before I set up the camera, I went back to my wireless hub and checked its settings.  It was set for “WEP, Open System, 64-bits, Hex.”  I copied all of these settings into the camera.  Then I uplugged the ethernet cable and power-cycled the camera, hoping it would connect to the wireless network.

It did not connect the first time, and I suspect I had some of the wireless settings wrong.  I ended up repeating the settings->disconnect->reboot loop a couple of times, and eventually succeeded.

I’ve got the camera set to upload an image via FTP every second.  It’s looking good!

Troubleshooting FTP Upload

The DCS-920 has a great facility for troubleshooting the FTP upload.  On the FTP Setup page (Setup >> FTP) there is a “Test” button in the “TEST FTP SERVER” section.  Pressing this button causes the camera to upload an image to the FTP server.  You can see the result of the test by going to the  Status page.

If all is well you will see the following message after a successful FTP upload.

FTP Server Test2010-08-11 04:04:43 Test succeeded.

I helped diagnose one user who was having upload errors and was observing the following error.

FTP Server Test2010-08-11 04:00:17 TCP/IP socket error.

This turned out to be because the user had not left the “Path” field on the FTP page the default value of “/” … and had mistakenly put a name like “/foo.jpg” in there.   The Path should be left as “/”.