The Lightwork web services are currently installed using the local customisations hook. It is now proposed to add them as core Moodle web services in Moodle 2.2. I have created a wiki page at http://docs.moodle.org/dev/Lightwork that describes the web services and the associated Lightwork database tables that will be required and would welcome all feedback and comments.
Recognising that the the Moodle 2.2 release date is now imminent, we are now aiming to add the Lightwork web services to the core Moodle web services in Moodle 2.3.
Initial design work has now been completed. Following web service forum discussions and investigation/prototyping we have decided to use Moodle REST based web services instead of SOAP. This avoids the issues of WSDL generation in the current SOAP implementation.
Additionally, the REST web services provide a very simple interface and will allow us to use JSON as a lightweight data format.
Just noting that you should be using the standard existing web service API (these are protocol-independent) for login and getting users etc (in 2.2), and that the new assignment module work (MDL-26997, targeted for 2.3) should be able to include everything else you need. You and Damyon can hopefully work together to make sure the new assignment provides all Lightwork needs out of the box (we will also use the same web services for the mobile clients).
It is not a working implementation yet, what we have there currently are:
- Proof of concept that we can port Lightwork-Moodle WebServices into Core Moodle as independant plugin instead of 'local' plugin as before.
- In that particular branch we are putting lightwork plugin under client category/type (I know this does not exist before), as we can't think of a logical place to put it under. I tried to put it under webservice before, but the webservice framework has assumption any plugin under its type is a protocol..so that does not make sense.
- Stub implementation of the Lightwork-Moodle API based on 2.X Moodle WS framework.
- Remove Lightwork-Moodle dependency on NuTech SOAP lib.
At this moment we are porting the API as-is our original design as documented in http://docs.moodle.org/dev/Lightwork, except to confirm it to the new webservices framework and token based security. Please let us know what do you guys think of these API calls. As you will see in http://docs.moodle.org/dev/Lightwork, most of the calls were designed to cater Lightwork need of processing a bunch of data at the same time. Our original thought was to better have minimum number of calls then having multiple number of calls to access the same set of data.
'local' plugin seems to me where your code should go. What is your reason to put your code in client/lightwork and not local/lightwork ?
>'local' plugin seems to me where your code should go.
Yes definitively. Especially because OK Tech WS which was the underlying framework of previous version of LightWorks have been moved to local/oktech and thus easily integrated in the official Moodle 2.0X plugin registration and authentication processes (either token or login/pwd) and protocols (soap, rest ...).
Up to now the Lightwork web services have always been implemented as a local plugin.
The objective of this phase of development is to include the Lightwork web services as part of the Moodle core code. The advantage of this is that when teachers wish to use Lightwork, the site administrator will no longer have to go through the process of downloading the appropriate web services from our site and follow the instructions to install it in the local directory. Instead, they will be able to "turn on" the web services through the Moodle administration interface. Lightwork users will then be able to connect to Moodle and enjoy the benefits of offline marking and marking management that the Lightwork client application provides.
Leaving Lightwork as a local plugin as you suggest would defeat the main purpose of this current phase of development which is to make the Lightwork marking tool more accessible and maintainable by including its web services, server-side code and database tables in the standard Moodle download.
Ah sorry I switched off the fact that Lightwork will go into core. In this case I would suggest a 'lightwork' or 'grade/lightwork' folder, but you should probably go to the Moodle dev chat to ask for it.
For the web service functions, the generic ones will go to other core folders (grade, course, user ...).
We'll use Moodle dev chat to agree the final location as you suggest. The reason we thought of client/lightwork is that we are imagining that in the future Moodle may wish to add more Moodle clients like Lightwork that access Moodle via it's web services framework.
I've started describing the web services that Lightwork proposes to contribute to the core at http://docs.moodle.org/dev/Lightwork#The_new_Lightwork_web_services.
We intend them to be generic enough so that they are of use to other clients beside Lightwork. We originally believed that we would need a separate folder in Moodle for Lightwork but now believe that all our web services can go into the separate core folders (grade, course, mod/assignment ...) exactly as you suggested.
the names look good. Minor things to fix:
=> as it is supposed in the Lightwork Moodledocs comments, core_webservice_get_site_info returns this information for each functions.
=>it should be renamed mod_assignment_get_assignment_submissions
=> it exists in core, it's called core_enrol_get_enrolled_users
=> that's kind of tricky. If the parameter is 'capability' then maybe the name is not correct. Or maybe 'capability' should be just one of the parameters. It seems like two functions in one. Which is not bad at the end as it could avoid two web service call. But in this case a new parameter should be able to tell the function to return either the courses either the assignments. Note we already have a function that return courses, we should avoid duplicating feature as much as possible. Finally the web service function is more related to assignments than course, it should be named core_assignment_... I think we need to discuss all that in its issue.
You should create an issue for each of the functions you want to add to core. I'll list these new issues in the web service Roadmap (MDL-29934).
This conversation and associated Tracker ticket have gone a little quiet over the past few months. Are there any plans to take this work forwards for future versions of Moodle?
The Lightwork team continues to work to incorporate Lightwork and its web services into the Moodle core. We anticipate the following:
Moodle 2.3 - This will contain the Lightwork "Marking Guide" and a number of web services that we have modified to be generic.
Moodle 2.4 - This will contain Lightwork marking management and the remainder of the web services. Lightwork will be fully incorporated, i.e it will be possible to use its functionality both in Moodle and offline.
Note that the marking management functionality of Lightwork and many of the web services depend on the new assignment changes being introduced in Moodle 2.3.
A belated thanks for the update. I've been interested in Lightwork for some time, so will continue to monitor the project as it is moves forwards through the current 2.3, and more so for 2.4.