Note:

If you want to create a new page for developers, you should create it on the Moodle Developer Resource site.

Mahara Portfolio Plugin: Difference between revisions

From MoodleDocs
(notes about mahara side)
Line 77: Line 77:
===Proposed mnet changes===
===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:
This section has moved to [[MNET_Roadmap]]
 
 
{| border="1" cellpadding="2" cellspacing="0"
|-
|'''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===
===Questions===

Revision as of 14:36, 22 July 2008

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

  1. 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
  1. 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.


Proposed mnet changes

This section has moved to MNET_Roadmap

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