Snap! to WMR protocol

WMR's usual architecture:

 * Web pages: running on user's browser
 * Django server: running on web server. (This is the "WMR front end")
 * Apache Thrift service infrastructure: Django interacts with a WMR JobService (Python) object, which Thrift transmits (via Thrift JobRequest objects) to the (Java-based) WMR backend
 * WMR backend: running on head node of cluster. This software services requests, such as:  submitting a WMR job; checking status; retrieving (potentially huge) results
 * Hadoop: running on cluster

Three options for interfacing Snap! with WMR
Listed in order in which to attempt them (apparently simplest to apparently most work):
 * 1) Write a Django view for Snap! interactions, and use HTTP (via ajax in JSON, possibly JSONP since the one page is local and the request is served from a remote server) for communicating those interactions between Snap! and Django
 * 2) Add Thrift to Snap! (about a 20KB lib file + implementation code), implement a WMR JobService object in Javascript, and have the Snap! block call methods of that JobService object. This approach uses Thrift to transform the output of the Snap! block into the thrift object format and then transmits that object to the pair thrift server-side service. The communication between the client-side thrift code is handled by either: a makeshift server(allows two way communication) via socketio.js (HTML5 lib), or over HTTP using an ajax call (still potentially working with json data). Probably easiest to maintain, but may add the most weight to Snap!
 * 3) Use JS to build a way for Snap! to talk to the WMR backend directly.  Most implementation work, hardest to maintain... (http(ajax) to a listener in the backend and adding handling)

Passing environment (closures)
In most languages supported by WMR, mapper and reducer functions are passed as strings from a web form without a program context, but Snap! mapper and reducer functions will be plucked from a Snap! programming environment, and may conceivably refer to variable bindings defined outside of those functions. Such environment bindings make up the closure of those functions, and if a mapper or reducer may have non-empty closures (apart from any predefined bindings for Snap!), those bindings must be passed along with those functions in order for WMR to perform its computations. Dan Garcia first reminded us that the Berkeley Scheme interface to Hadoop needed to pass such bindings, and pointed out that only bindings created or modified by a Scheme programmer needed to be passed (assuming that the Hadoop cluster already had the predefined Scheme bindings).

The St. Olaf team did not find an easy general strategy for passing the appropriate Javascript variable bindings directly from Snap! to WMR during our Summer 2012 investigation. However, since the Javascript mapper and reducer functions need to be serialized for transmission to WMR in any case, maybe bindings required for those functions can be packaged along with those string serializations. We anticipate sorting this out with Jens during implementation.