Thoughts on the future

[cannod]

Here is what I have been thinking about for this plugin...

I have had a look at the Joomdle code which connects Joomla with Moodle. They have created a whole bunch of custom Moodle web services functions so that Joomla can perform remote actions like create users, courses etc in Moodle.

Joomdle also provides a Moodle auth plugin that authenticates Moodle users with Joomla.

I started coding something similar for Drupal but it starting getting a bit messy.

If anyone is interested, should we create something like Joomdle but for Drupal?

1. Create custom Moodle web service functions. - Done.
2. User authentication using moodle-drupalservices auth plugin but instead of services module try RESTful Web Services module - https://drupal.org/project/restws as this module will be in Drupal 8 core.
3. On drupal side either hard code specific actions like when adding a user, call the Moodle web service function to also create a Moodle user, or plugin to rules so that we leave it to sys admins to create rules that fire off a Moodle web service function. I think the rules approach would give the most flexibility.

For example you could have a rule that gets run on checkout completion that enrolls a user into the purchased course all using Moodle web service functions.

I can post my code if anyone interested.

[netw3rker]

I think we should break this discussion into 2 parts: Getting a stable production ready release, and Where we go from there. Here's where I think we need to head for those points:

Stable 1.0 production release: 1) We aren't using the proper services implementations currently. We should be using the user level CRUD services instead of a services view. As well as the System Connect, and Session services. 2) Syncing user data is not scalable. We should be using either a pubsubhub model, or finding a way to only list changes so that a cron time of 1s is acceptable (not currently the case if the entire userbase is resynced every time). This can come in the form of a user level view that list users changed since a supplied date, paginated and ordered by uid. 3) the configuration instructions contain too many moving parts, and as illustrated by the number of open issues about it "not working" this is clearly causing problems. We should reduce the moving parts with step 1, then provide a "Feature" (as in the drupal features module export) that can simply be enabled). Additionally, the moodle configuration screen needs real time connection tests with prompts that tell the admin what works and doesn't so that proper configuring can take place.

Going forward: Version 2

RestWS: I'm onboard with switching to RestWS eventually. my main issue at present is that the usage level is low - at present 1k installs for RestWS vs 22k installs for services. This means that it's moving really fast under development and the D8 initiative is moving faster than D7. They already plan to deprecate/obsolete the module when D8 comes out, leaving a ton of potential users of this plugin in the cold till they upgrade. If we make the move to this, I'd say we might want to make it an optional interface rather than a required one. this way we support more drupal installs with V2 than just D8.

Deeper moodle service output: This is a decent level of interest in making Drupal become the ui and editor for moodle content, and i can see the need for a plugin that does CRUD for moodle objects, however I'm not certain that that is this plugin's job. If done, it shouldn't be specific to drupal, it should be service specific to the world so that other CMS's and service implementors can perform these actions against moodle. That sounds like the job of another plugin. From a data provider perspective, Drupal and Views already have the ability to query an report on moodle data with the moodle_views module http://drupal.org/project/moodle_views (I also co-maintain this - not to sound biased though)

I do like the idea of having drupal communicate directly with moodle to push user updates etc, and I really like the idea of using rules to do this. The method that was posted in one of the other issues where they simply run shell_exec() of the script is preety sleek. The one issue is that I think there's enough shared hosts out there that block the _exec() commands that this could be a 'buggy' issue. whereas a direct to services implementation might be the harder but more reliable road.

My one fear with providing communcation between 2 systems is always the "write fail" condition. its hard to be sure that updates were actually committed at the destination, and either a lot of code needs to be built to be sure that updates are sent before being marked as 'pushed' or a background sync process needs to exists at the destination. If we want to go the queue/push route, we could look at the Deploy module http://drupal.org/project/deploy for an already built deploy queue and delivery system for pushing these updates. It solves a lot of my fears in that regard. The sync process can be left as a background alternative as well.

Cross Domain SSO: I think this module is really being used and focused on as a moddle->drupal user connection system, and as such we should look to the future needs in this avenue. there are 3 kinds of SSO this needs to take into account: 1) resident app sso eg: http://exampledrupalsite.com/moodleinstall which was the initial solve and works 2) external same domain app. eg: http://moodle.drupalsite.com recently fixed with the cookie_domain fix 3) cross domain applicaiton eg: moodleexample.com [uses drupalexample.com]. This currently doesn't happen, and is already popping up in the issue queue.

Thats my $.02 on this, lets discuss!

[cannod]

Great thoughts and ideas.

I agree with your stable 1 release approach first. 1) When using the using the user level CRUD services, I thought at the time that I could not get all user fields such as firstname and lastname etc. That's why I went with a view. Maybe things are different now? 2) yep the sync script is very inefficient. In some ways I think it could be rid of if we push updates to moodle when required such as user creation/updates etc. "write fail" conditions would need to be considered but not impossible. 3) Totally agree with the too many moving parts. Simplifying the install process would be great.

In regards to V2 I think your ideas are great.

I've looked at http://drupal.org/project/moodle_views and this looks really cool. The only thing is that it uses moodle_connector which connects directly to the moodle database. I have reservations about direct modifications to the database and would prefer to use moodle's web service functions because at least then you can then use the Moodle API's.

In regards to SSO, I agree that this is where this module does pretty well once set up (and pulling some hair out doing so!) Getting cross domain to work would be awesome if we can get it to work.