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.
On the Mahara side
New core cronjob to process the queued requests
This will be called every 5 minutes and the function will be process_incoming_content_queue or similar.
New MNET functions
- portfolio/content_intent - Moodle signifies its intent to transfer content to Mahara and Mahara creates the user if necessary and returns no, queueonly or queueandwait
- portfolio/content_ready - Moodle has finished its part of the export and has prepared a file for Mahara to fetch. Depending on whether the transfer is happening interactively or not, Mahara will either queue the job for the next cron run to pick up, or initiate the transfer directly.
New database tables
There needs to be a table to store data between the content_intent and content_ready requests.
The table will look like this:
| Field | Datatype | Comment |
| id | integer | sequence. this is sent back to Moodle after the content_intent ping |
| host | char(255) | fk to host table |
| timestamp | timestamp | timestamp of initial content_intent ping (or maybe an expiry field instead) |
| userid | integer | fk to usr table |
| queue | boolean | whether a cronjob needs to pick this up or not |
| ready | boolean | whether moodle is ready for us to pick this up ornot |
relationship between dispatcher and artefact plugins
artefact_plugin base class will be changed to expect plugins to export a list of formats they can import from. This will be format/component (eg LEAP/entry or file/file) and maybe have a priority stored with them (or maybe the priority should be configured by the administrator) in case of multiple plugins supporting the same formats. At import time, the handler will unpack the file and dispatch to the appropriate artefact plugin to unpack it.
target formats
Nigel and I (Penny) discussed a lot the idea about the user being given the option to select where in Mahara their content will end up. Eventually we decided the best thing to do is that since for this iteration we are just supporting transferring files, to put them into an 'incoming' area in their files plugin. Later, we can get the mahara plugin in Moodle to redirect to a special page in Mahara for the user to select the target(s). We discussed making the targets be a part of the mnet protocol, but dismissed it as it's potentially too complicated to expect Moodle (even a Mahara plugin inside Moodle) to render this nicely to the user. At the point that we redirect the user to Mahara, we already have recieved a 'content_intent' ping, so we can just store this information in Mahara and use it when we unpack the content later and Moodle doesn't even have to know about it. The portfolio API's steal_control function supports this already so it will be pretty trivial to add later.
workflow
The more I look into this the more I think the best way to do this is:
- get the Mahara portfolio plugin to steal_control and send the user to Moodle's jump.php, with portfolio/add.php?postcontrol=1 as $wantsurl
- Jump.php in Moodle will redirect the user to Mahara's land.php, which will set up their SSO session and create their account if necessary.
- Modify Mahara's land.php to accept an extra parameter to indicate that $wantsurl is relative to Moodle's wwwroot, rather than Mahara's
- Bounce the user to $wantsurl (which is the portfolio postcontrol url)
This means that now the user is authenticated (or created) in Mahara and now we have a token to use to pass between Moodle and Mahara in the xmlrpc functions we need to call.
It does mean that we might have an SSO session where we don't actually need one.
I'm not sure how this will affect delayed communication between the two systems (eg queued transfers) as the SSO session may have expired?
Proposed mnet changes
This section has moved to MNET_Roadmap
Package format
As far as I can see there are two ways to approach the inclusion of metadata/manifest, either send it altogether in a file with a manifest (xml or txt), or send it in the content_ready xmlrpc call. Each one has its pros and cons. Either way this might be overkill now, but we do at least need a manifest to explain exactly what content we have. (And I think it's obvious we need to use a zip file)
Manifest.xml
The biggest obvious downside to this approach is that we need to define the format now, which is not something that we need to do really to just transfer file
bundled in content_ready
Having to store it in a temporary location between receiving it and unpacking the file and using it to create the artefacts
The simple approach
I would be tempted to do something like this manifest.txt:
md5sum:format:filename md5sum:format:filename
where format is something like FILE or LEAP
The problem with this is that eventually when we do something like LEAP, the content itself will be in a leap.xml file and the other files will just be associated content. This could probably be handled by doing
md5sum:leap:leap.xml
At the very least, doing it like this makes it easy to send a zipfile containing multiple files (very possible for this stage: multiple files uploaded to one assignment, for example)
Questions
- 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.
