Pluggable architecture for survey tool / VULab integration

[Peter Rowley]

Hi,

Ron, Blake, and I have been talking about the relationship between VULab 
and the survey tool.  As we've found with the work based on phpESP, it's 
not a good idea to let the survey tool drive the architecture of VULab. At 
the same time, it's daunting to rebuild a comprehensive survey tool with a 
good reporting system from scratch.  So I've proposed the notion of a 
pluggable survey tool.

VULab and the survey tool would communicate, on the user's client, via 
Javascript API's, one supported by the VULab application and one by the 
survey application.  The API's would look something like this:

VUlab -> survey tool:
- create a blank survey for the user to edit
- present the survey stored at URL XXXXX (a parameter) for the user to 
edit
- present the survey stored at URL XXXXX for a subject to fill out
- present the results for the survey stored at URL XXXXX
- delete the survey stored at URL XXXXX

survey tool -> VUlab
- the user has finished creating a survey which is now available at URL 
XXXXX

As part of the project, we'd have to build a simple survey tool that 
communications with VULab this way or, more likely, modify a tool such as 
phpESP that has a license compatible with Fluid's and that we could 
bundle.  But then if anyone comes along and says that they'd like their 
survey tool to work with VUlab, we give them the documentation on the API 
and encourage them to integrate with VULab that way.

This is the same kind of "mashup" integration used by many web 
applications with Google Maps, so it's not new by any means, and thus not 
too high a risk.

Blake is enthusiastic about this approach and is going to work with David 
and others to flesh it out.

Comments are most welcome!

Peter Rowley
York University
prowley at yorku.ca
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://fluidproject.org/pipermail/fluid-work/attachments/20080925/109eeb10/attachment.html>