I am returning from a very productive trip to Japan to participate in the 3rd Annual Ja-Sakai Conference (which I will blog about shortly) – but I did want to provide a quick update on the progress I have made in developing the Sakai 3 Basic LTI consumer widget. In my previous post on this subject, Sakai 3 Basic LTI Widget Sprint, I outlined five action items:
- At least one screencast demonstrating the work to date – probably two. One showing the Basic LTI plumbing and passing of the LTI certification tests, and another showing Sakai2 tool placements in Sakai 3 sites.
- Some of the information in an LTI launch needs to be secured from end users. This will be a chance for me to learn more about access control in Sakai 3; see: KERN-591.
- The widget itself needs some renovation. I will likely copy the existing Remote Content widget and add the LTI settings.
- Create some virtual tools for existing Sakai 2 tools and add these to the out of box Sakai 3 experience.
- Work on the Sakai 2 Basic LTI provider servlet to make it more robust and support the specific Sakai 2/3 integration use cases.
So let me address these in order:
- I still do not have any screencasts to show. I have made some significant progress on #3 so I am waiting to complete the UI overhaul before recording any screencasts. Please be patient – I will have something to show very soon.
- I am pleased to report that the implementation of securing the appropriate LTI launch parameters (i.e. secret and password) has been completed. Each launch node which contains the settings, now will have a sub-node which can only be read or modified by an administrative account. This sub-node contains the LTI secret and password. The service then masks the complexity of the implementation with this sub-node so that the user interface contract did not change. So the end result is that if the LTI related nodes are found via search or some other mechanism, we no longer need to be concerned that any related sensitive data will be exposed to unprivileged users.
- I am also pleased to say that some significant progress has been made on a new user interface for this widget. Using the code from the Remote Content widget is proving to be quite useful and delivering a nice user experience. There has been some debate about whether the Preview capabilities from the Remote Content widget are appropriate for this use case, but assuming that adding these capabilities to the service are not too time consuming, I plan on including this feature for user testing if nothing else. I personally believe the preview capability is worth providing, but I am willing to be proved wrong.
- No progress has been made regarding virtual tool registrations. I believe this use case is not unique and will extend beyond the Basic LTI needs. I have been procrastinating on this topic until I have the time to engage in the discussion fully. I expect that will be when the other action items are complete and we can apply focus to this one particular aspect of delivery.
- Some good progress has been made on the Sakai 2 BasicLTI provider. Through my work on BLTI-24, the provider is a bit more robust. And through Steve Swinsburg’s work on BLTI-31 we are now closer to having a tighter relationship between the Sakai 3 consumer and the Sakai 2 provider. This tighter trust relationship assumes the consumer is closely related to the provider (e.g. maybe within the same domain). I envision using this high trust configuration in conjunction with some auto-provisioning to keep a Sakai 2 and Sakai 3 system in synchronization, which we expect to be common for most hybrid implementations.