Mahara Portfolio Plugin

Initial communication between Moodle and Mahara

After the user has chosen 'Mahara' and clicked on an export to portfolio button, the first step that gets control passed to the plugin is the steal_control function, before process_stage_config is called.

At this point, Moodle should attempt to communicate an 'intent to transfer' to Mahara, giving it the necessary information about the user. Mahara at this point should create the user account if necessary. Mahara will send back one of three things - no, queue only, or queue and immediate. This is to indicate whether the transfer can take place while the user is waiting, or whether a queued transfer will be enforced by Mahara. Mahara should insert an 'intent' entry into a database table and send Moodle back the id, which Moodle will store in a queue table.

Config section

Moodle is then able to present the user with the config form, giving them the options of waiting (if allowed) as well as choosing the format to send the data in (this causes problems with the ordering of things - see Questions section), and any required metadata.

File ready ping

Once the user has confirmed the transfer, depending on whether the user has elected to wait or not, Moodle will either initate the package and send stages, or queue the item. Essentially these are the same. During both models, Moodle just sends a 'file ready' request to Mahara. In the interactive model, it also waits for the response from Mahara to say it has succeeded.

When Mahara sends the 'file ready' request, it also sends Mahara a location to retrieve the file from via a direct HTTP GET request. This is dependent on the file API in Moodle. As part of this request, Mahara will also send the original ID it sent back to Moodle in step 1, which Moodle is able to use to verify it should send the file.

Proposed mnet changes

As mnet evolves and potentially other services are offered than sso and enrolment, and potentially as more applications are written that talk mnet (there was a drupal mnet project, for example), it makes sense to start splitting out what services are offered by each application. To this end, I propse adding a new table, application2service, which links application to service, and moves the url field from the application table. It would look like this:

Field	Datatype	Comment
id	integer	sequence
applicationid	integer	fk to mnet_application
serviceid	integer	fk to mnet_service
url	char (255)	this is to replace application.sso_land_url (application.xmlrpc_server_url should still stay where it is)

I had originally thought about adding publishable and subscribeable fields to this table, but really I think this should be dictated by what the remote hosts offer. Not convinced on this point yet.

Questions

1. Ideally during the export config stage, Moodle should be able to let the user choose additional things, like what folder to put the outgoing file into. However, because the user doesn't select the export format until this same stage, this isn't possible. There are two options here, either just automatically put the files into an 'coming' folder in Mahara, or add an additional step to allow the user to select the target location. (Note that this holds regardless of format - blog posts that are being transferred natively (not for this development phase but potentially later) would benefit from the user being able to specify the target in Mahara.

See Also

Portfolio_API