Vital Source Technologies recognises the benefits that the IMS Learning Tools Interoperability (LTI) 2 specification can deliver to tool providers and has, therefore, agreed to sponsor this project in the interests of the whole community. The work will be undertaken in collaboration with Moodlerooms as an adaptation of the existing LTI (External tool) module which they manage on behalf of the Moodle community.
The main goal of this project is to implement LTI 2.0 functionality for Moodle which is capable of passing the IMS certification tests. It is not expected that the required changes will have any significant impact on the current LTI 1.1 functionality; indeed it is hoped that the work will also have some beneficial side-effects for the current LTI implementation.
A full description of the proposed work can be found at http://docs.moodle.org/dev/LTI_2_support.
One of the current issues arising from this work is whether the extensible services introduced with LTI 2.0 (and 1.2) should be implemented using the existing LTI Source plugin functionality. One of the purposes of LTI Source plugins is to extend the LTI protocol, however, this does not appear to be implemented in a manner consistent with the latest LTI specifications. For example, there does not appear to be a way for Moodle to announce the availability of these extensions so that other parties can discover them.
The "Defining services" section of the project description outlines the properties and methods expected to be required for adding extensible services under LTI 2.0. I suspect this could be bulit upon the existing LTI Source plugin framework, but I have not seen any examples (apart from a simple Dummy plugin) of its use so I don't have a feel for whether this might be welcomed by current users of the framework or if it might be better to keep it separate. Is there a demand for non-discoverable services or might these be migrated into the new discoverable approach? I am also aware that this framework can be used for more than just services, but can be used to create sub-plugins.
I would welcome comments from anyone who is using the LTI Source plugin framwork. Thanks.
Better implement the updated spec and the LTI 2 - ToolProxy, Since no one seemed to implement and LTI source plugins so far.
I am very much looking forward for this, since one of the first plugins I wish to implement is an xAPI (TinCan) plugin, which could widely expand the tracking of student progress when using the TP service.
Could I also highlight https://tracker.moodle.org/browse/MDL-39134 as another thing you might be able to cover during this?
I suggested a filter, but maybe an Atto plugin / change to the Link option in the editor would be another option.
The underlying idea is that currently it isn't practical to add LTI links to external resources within the flow of a content page (loose term for anything teachers can edit - page/book/question in a quiz/forum post/...)
A screencast of the proposed implementation for LTI 2 is now available at http://www.spvsoftwareproducts.com/temp/lti2-moodle/ so you can see how it works and how few changes to the existing functionality have been required.
I have added the LTI Provider plugin to my site, and set up the various parameters. Then, from a second Moodle site I have linked to my Provider site using the secret key, secret URL etc. but all I come to is my provider site login screen. I admit I am a little confused about where I can find my customer key, or where I can set it.
Any help on this would be very much appreciated.