David Goodrum asked me to provide an update to the Oncourse Priorities Committee  regarding the progress made towards Sakai 2->3 integration and migration. In doing so, it became clear that this kind of update might also be useful to the community at large. There are two overarching goals to achieve in this project: 1) seamlessly exposing Sakai 2 functionality within Sakai 3 (which we are dubbing “hybrid” mode) and 2) content migration.
The hybrid mode will allow institutions to adopt Sakai 3 at a pace that is comfortable for them. For example, Sakai 3 will not have all of the functionality available in Sakai 2 day one, but their will be some compelling functionality that institutions will want to adopt before all of the functionality gaps have been closed. Hybrid mode will facilitate this approach by allowing institutions to deploy Sakai 3 and take advantage of the new features while still relying on Sakai 2 for the features not yet available in Sakai 3. The following video demonstrates the first step in realizing hybrid mode: the ability to expose entire Sakai2 sites within the Sakai 3 portal.
We anticipate that institutions will want to start using Sakai 3 for full-fledged project and committee work before course work. This capability supports this use as Sakai 3 sites can be used for project sites while Sakai 2 continues to serve the course site needs. The next step in the hybrid mode evolution will be the ability to place individual Sakai 2 tools onto Sakai 3 pages which live in Sakai 3 sites. This will give the user the ability to mix and match both Sakai 2 and Sakai 3 functionality in a single user experience.
Next: content migration. The primary use case that we are tackling first is the ability of an instructor who taught a class last semester in Sakai 2 to be able to import that site template into Sakai 3. The following video demonstrates an initial deliverable where one can export content from a Sakai 2 site and then import that content into a Sakai 3 site. Please keep in mind that this is very early work and is rough around the edges, but the methodology and underlying service is sound.
Moving forward, focus in the following areas is required:
- Exposing individual Sakai 2 tools on Sakai 3 pages within Sakai 3 sites.
- Exploring a results mechanism so that a tool hosted in Sakai 2 can report results to a tool hosted in Sakai 3 (and vice-versa). As an example, you might want to use a Sakai 3 Assignments tool which will need to report outcomes to a Sakai 2 Gradebook.
- Continued effort to import Sakai 2 site templates into Sakai 3 for semester-to-semester transitions.
- Deeper content migration that will not only transfer site templates, but also include full user content. For example, this will likely be a requirement to migrate a project site from Sakai 2->3.
I am pleased to update the Sakai community on the outcomes of a two day coding sprint to produce a Basic LTI consumer widget for Sakai 3. Dr. Charles Severance, Noah Botimer, and I participated in the sprint which the University of Michigan CTools team was kind enough to host. Don’t worry if you are not familiar with the Basic LTI specification. It is an up and coming specification from IMS which is currently in draft status. In a nutshell, it allows separate applications to be loosely integrated through an IFRAME. In the first iteration, known as “Basic” LTI, the remote system trusts some user information from the local system such as the identity of the user and the roles of the user (e.g. Instructor, Learner, etc.), and then automatically provisions accounts and tools appropriately. Essentially, this allows a remote tool to appear in a learning management system (LMS) as if it were a local tool. From an industry perspective, this will allow a standard way for say publishers to provide hosted textbook content to a variety of LMSs. It could also create an environment where we begin to select tools à la carte for inclusion into a local LMS implementation; i.e. selecting the tools that best fit the pedagogy used by the instructor. For a quick primer on LTI, I would suggest watching the video IMS Basic Learning Tools Interoperability by Dr. Chuck.
So the reason that I wanted to explore LTI was perhaps a bit less lofty. Simply, I wanted to use it as a mechanism to place a Sakai 2 tool into a Sakai 3 site as a widget on a page. The work that has been accomplished to date (see: Sakai 2+3 Hybrid Status Update) has been largely about exposing entire Sakai2 sites in the Sakai 3 portal. This work is still very much applicable, but supports a different use case than what I hoped to accomplish with an LTI widget. In this case, we want to be able to support a mixture of Sakai 2 and Sakai 3 tools and widgets within the context of a Sakai 3 site. This will help us make the transition from 2–>3 without a “big-bang” approach. For example, Sakai 3 will not have a PostEm tool day one, and that should not present a roadblock to Sakai 3 adoption. You should simply be able to place the PostEm from Sakai 2 in your Sakai 3 site along with all of the other native Sakai 3 widgets.
So after two days of intense coding, we had a widget that could consume a sample Basic LTI Provider. Many thanks again for the help from Dr. Chuck and Noah Botimer! You guys are awesome! There was certainly more work to do, but the plumbing had been laid and now I could focus on refining working code. Beyond the mechanics of creating an LTI launch, we wanted to add some settings to the widget:
- Create “virtual tool” registrations so that the same widget could be provisioned many times under different names; i.e. the same widget could be reused for sakai2.calendar, sakai2.postem, sakai2.etc.).
- Allow for administrative control over Basic LTI widget placements; i.e. the system administrator could define default values and/or lock settings that could not be modified by instructors. For example, you could use these locked settings to create the virtual tols described in #1.
- Settings to control user privacy:
- Should the user’s name be released to the remote system (i.e. first, last, full names)?
- Should the user’s email address be released to the remote system?
- Should the user’s user-name be released to the remote system?
I spent the next week wrapping up these enhancements to the code. The next step was to invoke the Basic LTI provider that is currently slated for release in Sakai 2.7.0. I mean that was the whole point of this exercise after all! In doing so, I discovered a bug that cause the Sakai 2 provide to choke – it did not like the “/” character in my context_id variable; see: BLTI-23. The shortest path to resolution was rolling my sleeves up and fixing the code. So along the way, I accepted an invitation got wrangled into becoming a committer on the BLTI project! After fixing BLTI-23, we decided that the length of the Sakai 2 siteId could be a problem as we cannot predict the length of context_id that remote systems will pass, so next came BLTI-24. A few commits later, and the we were in business! Yeah! I could display a Sakai 2 within a Sakai 3 site placed as a widget on a page.
So what is next?
- 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.