Hi all,
As you know, we're still in the midst of evaluating technologies for
the Fluid Engage services layer. The services layer is the part of
Engage that is concerned with managing and sharing data throughout the
system. It will import and share data from collections and content
management systems, and will also provide connections to the social
networking and collaborative features of Engage. In short, the
services layer is the place where we share information about exhibits,
offering features such as search, tagging, commentary, and so on.
Our goal is to build a system that is lightweight and approachable,
using a familiar dynamic language that is well-suited to the
functional and declarative approach we've used with Infusion. At this
point, I've pretty much narrowed the choice of programming language
down to two: Python and server-side JavaScript.
As many of you will remember from recent architecture meetings, we've
had some concerns about the prospect of server-side JavaScript;
namely, the lack of existing web container infrastructure and issues
around performance and threading. On the other hand, using JavaScript
on the server would allow us to reuse many of the features in
Infusion--particularly the Renderer and ChangeApplier--to build rich
applications quickly.
I recently stumbled across a few tools that appear to make JavaScript
on the server more viable. It all starts with the ServerJS group at
Mozilla, a team working to define a base set of specifications for
server-side JavaScript environments:
https://wiki.mozilla.org/ServerJS
Among other things, this group has developed a standard for loading
JavaScript code as self-contained, packaged modules:
http://askawizard.blogspot.com/2009/03/interoperable-javascript-modules.html
They've also defined a standard library for doing things like
accessing files, making HTTP requests, and so on. A promising
implementation of this standard library and module system is Narwhal:
http://narwhaljs.org/
Most importantly, they've also developed a standard web container
contract called JSGI. It provides a simple, low-level API for how
requests and responses are processed in JavaScript. It is analogous to
standards in other languages--WSGI for Python and Rack for Ruby. JSGI
ensures that we'll have a viable model for porting code between
JavaScript runtimes:
http://jackjs.org/jsgi-spec.html
Jack is an implementation of the JSGI spec, providing adaptors for
several prominent servlet containers using Rhino, as well as the v8cgi
project, a FastCGI adaptor for Google's V8 engine. Jack promises to
get us up and running fast with JavaScript on the server, starting
with the JVM for simplicity:
http://jackjs.org/getting-started-with-jack.html
To be clear, this stuff is still incredibly new, but it represents our
most viable option for running JavaScript on the server. I've been
doing some early experiments with Jack, and Michelle has picked up
this work and is starting to run performance benchmarks on the
platform. From there, we'll sync up with David's work writing a data
importer for McCord's XML in JavaScript, and get a better sense of how
viable this is. At the same time, Yura is cooking up a Python
implementation of the data importer service for comparison. Antranig
and I have also joined the #jack-js and #serverjs channels on
freenode, and have introduced ourselves to the community.
Exciting stuff, and I'd love to hear your thoughts about it.
Colin
---
Colin Clark
Technical Lead, Fluid Project
Adaptive Technology Resource Centre, University of Toronto
http://fluidproject.org
_______________________________________________________
fluid-work mailing list - [email protected]
To unsubscribe, change settings or access archives,
see http://fluidproject.org/mailman/listinfo/fluid-work
