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 6 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 current 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 play nice. At the same time, it 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. 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 list of the options 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. A compilation of notes and ideas from these conversation has been maintained by Antranig Basman and Colin Clark at the Fluid Engage Server-side Technology page.

Some Background Thinking

  • MVC and the proliferation of controllers
  • Goal of ubiquity
  • Infrastructure and being at the bleeding edge

JavaScript on the Server

Portability and JSGI

Next Generation Runtimes

Rhino and the JVM

Tying it all Together

  • No labels