Next steps for the Engage services team

[Colin Clark]

Hi everyone,

Here's a quick summary of the tasks the Engage services team currently  
have on our plates. Right now, we're working with McCord's artifact  
data in XML format, using it as an opportunity to sketch out the  
services architecture and sink our teeth into some real-world  
scenarios. We're writing a few test services to convert this data into  
JSON and persist it inside CouchDB. With this, we'll also create a  
data feed that provides information about objects within an exhibit.

Summary so far:
  * Yura has created instructions for getting CouchDB up and running
  * He's also written a Python app to convert data from XML to JSON
  * David is going to build a similar app in JavaScript
  * Michelle's sketching out the API for our data feed, using existing  
museum APis as an example
  * I'm analyzing technologies, working towards a proposal for our  
services technology stack

Related JIRA issues:
  * http://issues.fluidproject.org/browse/FLUID-2809
  * http://issues.fluidproject.org/browse/FLUID-2901

On the JavaScript side of things, I'd like to see the performance  
impact of using a pure-JavaScript XML parser in comparison to one  
implemented natively in the browser. We have an XML pull parser that  
was built for the Renderer that should be suitable for this, but it's  
hard to use.

David, can you start in on writing a browser-based implementation,  
using the DOM to convert from XML to JSON? Antranig has agreed to  
write a version using the pull parser as a comparison. These two  
examples should give us a good, hands-on comparison of performance  
between several flavours of JavaScript and Python.

So here's a plan for next steps:

1. Write an app that converts XML to JSON inside a browser using  
jQuery and the native DOM. (David)
2. Get an equivalent app working in Rhino on the server using our XML  
pull parser. (Antranig)
3. Devise a scheme for benchmarking these various implementations  
(Yura and Antranig?)
4. Compare the performance of #2 in a modern JS runtime on the server,  
such as V8 CGI (Yura?)
5. Sketch out the API for our artifact data feed (Michelle)
6. Get these tasks into JIRA, and start talking about our work on the  
list and in the channel (everyone)

Where will all this benchmarking and experimentation lead? The goal  
here is to move quickly from research into real, useful code that  
supports creating great exhibit experiences on the web. The community  
is starting to design and implement user interfaces for displaying  
information about artifacts on a mobile device. The services layer  
will be the key to providing open access to museum data throughout the  
Engage system. We'll be settling on a firm technology stack for the  
services layer in the next couple of weeks, and then we'll take one of  
the experimental service implementations and start to polish it into  
production-worthy code.

Colin

---
Colin Clark
Technical Lead, Fluid Project
Adaptive Technology Resource Centre, University of Toronto
http://fluidproject.org