JSON-RPC work in progress

[derrell at samba.org]

This is a brief overview of my ongoing work to allow remote procedure calls to
be issued by a javascript application running in a browser, to the Samba4
embedded web server.

With the growing popularity of having "real" applications running locally in
the browser, the ability to make synchronous or async remote functions calls
from the browser to the server provides a huge increase in capability for the
applications.  Instead of just using basically static pages generated at the
server, or even locally-generated pages using data provided with the page
initially, remote procedure calls allow for dynamic modification of the gui to
fit the changing environment seen at the server.

Initially, this functionality will likely be used to provide a SWAT-like
capability, for configuring Samba4.  The possibilities, however, exceed this
simple use.  With remote procedure calls, it would be possible, for example,
to provide a "Network Neighborhood" capability which runs in the browser.

JSON is an acronym for "Java Script Over the Network".  It provides an
encapsulation of data that is fairly easy to generate in javascript, trivial
to parse with any normal browser's javascript implementation, and fairly easy
to generate and parse in languages other than javascript.  JSON is typically
sent from browser to server (and vice versa), and _something_ on the server
parses it.  That _something_ could be a PHP script, Java, etc.  In our
implementation, we have embedded javascript (ejs) available at the server, so
we can parse the JSON message directly back into its javascript form.

JSON-RPC is a mechanism for issuing remote procedure calls and retrieving the
response, passing the requested procedure name and the parameters in a JSON
message, and receiving a reply encoded as a JSON message.

qooxdoo is a javascript framework for easily creating "real" applications to
run in the browser.

There is a web page describing JSON-RPC (http://json-rpc.org).  Unfortunately,
the "standard" is very incomplete, and different implementations have had to
make various changes to accommodate real-life requirements.  We on the qooxdoo
team have a working implementation, and have documented our implementation so
other server implementations have a way to be compatible.  The JSON-RPC server
in Samba4 will be qooxdoo-JSON-RPC compatible.  The test framework includes
qooxdoo applications for verifying that the JSON-RPC functionality is
operating properly -- the same qooxdoo applications that already run
successfully against the PHP and Java implementations of the JSON-RPC server.

I have already implemented some large portions of the Samba4 JSON-RPC
functionality:

- ejs doesn't provide the standard javascript capability of parsing the JSON
  messages.  I've implemented a parser which is now callable from javascript,
  to parse JSON messages. (source/scripting/ejs/literal.c)

- There's now a JSON formatter for taking any arbitrary javascript object and
  generating its literal form, aka a JSON message. (jsonrpc/json.esp)

- The JSON-RPC generic server receives each JSON-RPC request, ensures that the
  requester is allowed to issue the requested call, determines which
  javascript file implements that call, handles various generic errors,
  dispatches the request, and generates the JSON reply message.
  (jsonrpc/request.esp)

- In order to both test the JSON-RPC server functionality and to provide an
  example of how to implement RPC methods which may be called from the browser
  application, I've ported the set of qooxdoo test methods.
  (jsonrpc/qooxdoo/test.esp)

The JSON parser and formatter are tested to a small degree, and appear to be
working.

The JSON-RPC server is written and parses successfully by ejs, but it has not
yet been tested, and is not quite feature-complete.  Similarly, the qooxdoo
test method suite parses but has not yet been tried.

Time permitting, I am hoping to have the JSON-RPC server and the qooxdoo tests
running successfully this week.  I'll then add methods for Mimir's libnet
functions so they can be called remotely, and then provide methods to call
various other ejs-available functions.  



Whew, I actually got this posted "this weekend" (at least in my timezone), as
promised. :-)

Derrell