Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 10 Next »

Goals & Criteria

  • Broadly approachable
  • Hit the ground running
  • Interoperable
  • Scalable and forward-looking
  • Fits the approach of the Fluid community: functional, declarative, Web-oriented

A broadly approachable services layer technology lets us reach out to a large number of Web developers, allowing them to get involved in the Engage community and technology using skills and languages they may already be familiar with. Similarly, the Fluid community itself needs to hit the ground running with Engage, building the services layer in technologies that are familiar and will get us coding with minimum ramp-up time.

Interoperability is a primary goal of Engage, ensuring that our technologies will work with a wide range of existing authoring tools, content management systems, and other tools commonly found in museums and on the Web. The Engage services layer needs to fit in well and leverage open standards wherever possible.

At the same time, our choice for server-side technology needs to be scalable and forward-looking, allowing museums to invest in Engage over long run, without fear that our services will slow down impossibly when confronted with large collections, and that they won't quickly go obsolete.

Lastly, the Fluid community has built up, over the years, a set of techniques and philosophies for writing software: accessibility, the Open Web, functional programming, and markup agnosticism are common themes throughout our technologies. As a community, we embrace diversity and a wide range of styles; shared patterns and techniques in code help make our solutions more coherent and consistent to develop with.

Candidates We Considered

We explored a variety of potential technologies for the Engage services layer. In each case, we considered both a programming language and an accompanying Web framework, recognizing that much of the advantage of a particular language comes from good tools we can reuse. Here's a short list of the major technologies we considered:

  • PHP
  • Ruby + Merb
  • Python + CherryPy
  • Server-side JavaScript: a) JVM + Servlets + JSGI, and b) V8CGI or other next-generation runtime + Apache module

We explored each of these options through a series of conversations with the Engage development team and the wider Fluid community. An in-depth set of notes and ideas from these conversations is available at the Fluid Engage Server-side Technology page.

Some Background Thinking

Our Process

Making technology decisions early in a cutting-edge project can be fuzzy and difficult. The goal here was to look at a range of potential server-side languages and Web frameworks, narrowing in on an approach that provides our community with enough flexibility to adapt and change over the course of the project.

Arguably, our evaluation wasn't particularly scientific, though we did perform some fairly comprehensive performance benchmarks as we started to narrow down our choices. It's hard to quantify many of the criteria of a successful development environment; our aim was to find a language and accompanying framework that fit both the technological needs of our users and the culture of our development community. Throughout the process, we carefully examined both the features and the context of a particular technology: what it has to offer both in terms of technical solutions as well as the associated community, documentation, and support.

MVC Frameworks

Many of the most familiar Web framework, regardless of language, tend to take a roughly similar approach to structuring code along the lines of Model, View, and Controller (MVC). This particular style of Web MVC can broadly be described as Rails-inspired, and is shared by technologies such as Django, Merb, and others. In short, this approach tends have the following characteristics:

  • Models, or entities, have a direct mapping to database tables through a object/relation mapping (ORM) layer
  • Views are HTML templates and the associated code required to map and render the model
  • Controllers fill in the glue between this, providing various other responsibility including URL routing

In context of Engage, typical MVC frameworks have a number of weakness. Foremost among these is that with Engage's schema-less approach, the ORM-driven model scaffolding offered by such framework affords us little advantage.

Associated with this, such MVC frameworks tend to provide a 1:1:1 mapping between a model object, a view, and the controller that mediates them. This structure works well for some sites, particularly ones that provide fairly static view of content to end-users and require extensive back-end administrative interfaces. Engage re

this For rapid development of commercially-oriented sites has a number of weakness. With the schema-less approach...

While much has been said about the alternative MVC approach we've taken in Infusion...

Web Framework Standards

Server-side Web frameworks continue to proliferate in a broad range of languages. Java is probably the most extreme example of the range of tools available to choose from, but Ruby and Python increasingly reflect similar diversity. With this range of options, portability between Web servers and containers becomes more difficult.

One pattern we noticed while researching various server-side languages and frameworks was the increased standardization of simple Web container APIs. These APIs make it easier to port code between frameworks and ensure that there is common low-level infrastructure across competing frameworks. While the Servlet API is a familiar standard for the Java world, APIs such as Python's WSGI (Web Server Gateway Interface) and Ruby's Rack spec are available for dynamic languages, too. JSGI, a similar API for server-side JavaScript is described below.

While these technologies aren't sufficient in themselves to write a Web application against, they make portability across environments much easier.

JavaScript on the Server

Portability and JSGI

Next Generation Runtimes

Rhino and the JVM

Tying it all Together

  • No labels