processing webserver, notes
I started to revive an older version of a processing webserver (sHTTP) i wrote a while back which allows to control processing applications through a website based interface. First thing to get replaced was the server implementation with NanoHTTPD by Jarno Elonen and Konstantinos Togias. Works smooth and well, but I am giving my considerations another round of thought and will look into node.js and comet [1][2]. The web interfaces will be using jquery, ajax, socket.io to communicate with the processing application. The webserver will respond to requests by sending back static files stored inside a folder included in the application or will respond with on-the-fly-http-responses. Here i am looking at using json rather than xml to communicate between server and client.
What is the benefit of running a webserver within a processing application?
Control. It allows users to remotely connect to an app via a web browser. Clients here could be a desktop, laptop or any mobile device (iphone, ipad, android, etc.) which is connected to the same network.
Interface. The user interface design can be build with and make use of powerful javascript solutions like jquery.
The downside of HTTP and AJAX is that it is quite costly and slow. Each request requires a round trip communication, whereby a request is sent for each update and the server responds accordingly. Therefore using websockets would be the way to go. “Unlike traditional AJAX, in which each XMLHttpRequesconsists of a round trip which sends and then receives data from a remote server, a Web Socket sends and receives asynchronously on a single connection. This allows WebSockets to Reuse the same TCP stream, ’Push’ data to the browser and skip redundant HTTP headers.” sys-con.com
Good things to come with html5, the WebSocket API, “This specification defines an API that enables Web pages to use the WebSocket protocol for two-way communication with a remote host.” w3
