Hi everyone,

Just a quick report on some work using Apache Wookie (Incubating) (see http://incubator.apache.org/wookie/)

I've done some initial investigation into mapping the BasicLTI launch request onto the REST API that Apache Wookie uses for largely the same purpose. Of the 23 launch fields in BasicLTI, there are five that can be used:

1. "resource_link_id" maps onto the Wookie "shareddatakey"

2. "user_id" maps onto both the Wookie "userId" and "participant.userid" (usually, but not necessarily the same thing in Wookie)

3. "roles" does not really map exactly, but can be used to set the current viewer to the owner (as per OpenSocial) or just to set a "isModerator" preference value.

4. "lis_person_name_full" can be mapped to Wookie "participant.displayname"

5. "launch_presentation_return_url" can be used for error response redirection

The other 18 parameters aren't really necessary. Some comments:

- I can see "launch_presentation_locale" usefully mapping to Widget localization at some point, though this means a bit more work.

- "launch_presentation_document_target" is problematic as it doesn't match the W3C ViewModes and Media Query specs which is how we'll handle any different Widget presentations.

- I found it odd there was so much administrivia in the request spec, yet it didn't have a link to a user avatar pic! Don't most LMS's have user icons now?

I've implemented this using Chuck's sample code ("lms.jsp") as the consumer connecting to a Wookie server and launching various widgets such as chats, voting, etc. This seems to work OK, though I haven't really tried processing the oAuth token (Wookie just uses API keys). The implementation is an extra servlet that sits alongside the existing REST API. Let me know if you want the code - its just one java file.

I think implementers would probably find it easier to just implement the Apache Wookie API rather than reuse a BasicLTI connector - for example, Wookie already supports "app store" type functionality such as categories, gallery metadata, app icons, etc. So while an education application might initially use a BasicLTI connector I think as soon as the developers gained an understanding of the functionality they would migrate to using a Wookie plugin, as these are pretty simple to write. For apps that aren't education-specific you'd probably start out with a Wookie and/or Shindig plugin anyway.

It would however be useful to identify where there are requirements that aren't met by current code and specifications. For example I think there is a need for more generic user tracking services, rather than the "enterprisey" stuff in Full LTI. (see, for example Chuck's post at http://www.dr-chuck.com/csev-blog/000660.html and also Michael's post at http://mfeldstein.com/moodle-wave-and-widgets-oh-my/ )

S

(reposting as the first attempt didn't seem to take)

I worked with Scott to connect the Wookie server to BlackBoard, WebCT, Desire2Learn, and Sakai. It worked quite nicely. Here is a blog post with all of the details and screen shots of Wookie working in all three LMS systems:

http://www.dr-chuck.com/csev-blog/000672.html

I am pretty excited about this development. I will be joining the Wookie team to support BasicLTI in Wookie.