Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.


Couch specifically addresses the schema problem we face in Engage. Data is stored as documents in JSON format, making it particularly useful for use in client-side applications that make heavy use of JavaScript. CouchDB Views, the means for filtering, aggregating, and retrieving data from documents in the database, are written in JavaScript and can be used to make various data feeds from a collection of documents. This provides a solution that fits neatly within Engage's open Web architectural approach, and is approachable to a wide range of developers.

Data in Couch CouchDB is queried and persisted saved using a RESTful API: fetching data requires involves a standard HTTP GET request, while adding or updating documents is , just a PUT or POST operation. This means that Couch can be used with any programming language without required extra native database drivers. It's also an excellent fit for a RESTful service-oriented architecture. For museums that already have their own databases or CMS systems, Couch can be replaced with a custom service that provides the same RESTful operations and feeds as provides by the Couch Views that will ship out of the box with Engage.


We will continue to assess Lucene's associated Solr project, which provides a RESTful API and JSON-based wire protocol ideal for Engage's architecture.


JavaScript on the server, while still on the bleeding edge, provides us with an broadly approachable environment for writing server-side code using many of the existing tools offered by Fluid Infusion.

Rhino and the JVM

Currently, the most mature and reliable environment for running JavaScript on the server is Mozilla's Rhino. Running with a Java Virtual Machine, Rhino is used widely for embedded scripting in many Java applications, and also ships as part of the standard Sun Java 6 JDK. As a result, Rhino is widely tested and stable.

Rhino's JavaScript runtime is based on the SpiderMonkey engine that shipped in Firefox 2. As a result, it offers acceptable but uninspiring performance for most Web application tasks.

Rhino's deployment within the JVM brings with it a number of advantages. We can leverage the Servlet API to provide us with a proven interface to Apache and other Web servers. Since threading in Java is well-establish, and the Servlet API offers clear semantics for concurrency, the JVM offers an easy way to establish a container and framework that is scalable and concurrency-safe.

Where necessary, we can also leverage other libraries that are available in Java. However, to be very clear, we will limit our use of Java within the Engage services layer to only situations requiring extremely fast performance (such as converting data in bulk) or to clear, easy-to-port algorithms.

Next Generation Runtimes

Portability and JSGI

With a plan to build first on Rhino and the JVM, and move to a next-generation runtime as soon as the required Web infrastructure is established for one of these, the obvious problem is portability. If we commit to Rhino now, will be able to move to V8 or Tracemonkey later?

The JSGI spec provides a solution to the portability issue. Modeled after Python's WSGI and Ruby's Rack, JSGI provides a simple contract for containers when managing requests and responses. JSGI is well-suited to JavaScript's functional style, and is relatively straightforward to implement. By coding to JSGI, the Engage server-side technology can be trivially ported from Rhino + Servlets to V8CGI or another next-generative runtime.

Env.js for Browser Compatibility

One of the goals of JavaScript on the server is to provide a natural and easy-to-learn environment for developers who are familiar with client-side JavaScript programming in browsers.

Tying it all Together

  • Assemble our own framework Kettle by combining JSGI, Env.js, and Infusion