Goals & Criteria
- Broadly approachable
- Hit the ground running
- Scalable and forward-looking
- Fits the approach of the Fluid community: functional, declarative, Web-oriented
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.
Some Background Information
In-depth information about our approach to evaluating technologies, along with our observations, is available at the Fluid Engage Server-side Technology Notes page.
CouchDB and Lucene
Data Feeds and CouchDB
There is an incredible amount of diversity among museums in terms of how they each organize their collections and structure their data. Each museum's collection is different, and it is a daunting and risky task to attempt to force all types of collections into a single schema. Engage will need to embrace this diversity; rather than creating a "one size fits all" approach at the database level, we'll take a flexible approach to schemas in Engage.
Written in Erlang, Couch is extremely scalable and can meet the requirements of massive, complex collections and exhibit data.
Free Text Searching With Lucene
Users have come to expect natural, Google-like text searches from most modern Web experiences. As a result, Engage will need to include a free text search engine service.
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.
Rhino and the JVM
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?
Env.js for Browser Compatibility
Tying it all Together
- is familiar and broadly approachable, both by our community and by the majority of Web developers
- allows us to reuse existing code and infrastructure such as Fluid Infusion, allowing us to get started fast
- enables us to deploy components and markup either on the client or the server, based on device or app requirements
- can scale to meet the needs of museums with large collections and many users
- is unlikely to become obsolete in the future
- Assemble our own framework Kettle by combining JSGI, Env.js, and Infusion