開発:Maharaポートフォリオプラグイン

作成中です - Mitsuhiro Yoshida 2008年10月21日 (火) 18:05 (CDT)

Moodle - Mahara間における、最初のコミュニケーション

ユーザが「Mahara」を選択して、「ポートフォリオにエクスポートする」ボタンをクリックした場合、process_stage_configがコールされる前、最初にプラグインにコントロールを渡すのは、steal_control関数です。

この時点で、Moodleはユーザに関する必要な情報を提供して、Maharaとの「転送の意図 (intent to transfer)」の通信を試みます。また、Maharaは必要に応じて、ユーザアカウントを作成します。Maharaは次の3つの中からひとつを送り返します - なし、キューのみ、キューおよび即時処理。これは、ユーザが待っている間、転送を実行できるか、キューに入れられた転送がMaharaによって強制されるか指示します。Maharaは、「intent (意図)」エントリをデータベーステーブルに挿入して、Moodleがキューテーブルに保存するIDを戻します。

Configセクション

それから、Moodleはユーザにデータが送信されるフォーマット、必須のメタデータ (これは、データの並び替えで問題が生じます - 詳細は問題セクションをご覧ください) と同時に (可能であれば) 待機するオプションを持ったconfigフォームを提供することができます。

File ready ping (ファイル準備完了ピング)

ユーザが転送を承認した場合、ユーザの待つか待たないかの選択に応じて、Moodleはパッケージを起動してステージを送信するか、アイテムをキューに入れるか判断します。基本的に、これらは同じです。両モデルにおいて、Moodleは単に「ファイル準備完了 (file ready)」リクエストをMaharaに送信します。インタラクティブモデルでは、同様にMaharaからの成功レスポンスを待ちます。

Maharaが「ファイル準備完了 (file ready)」リクエストを送信する場合、同様に直接HTTP GETリクエスト経由でファイルを取得するためのロケーションをMaharaに送信します。このリクエストの1部として、同様にMaharaはステップ1でMoodleが返してきた、Moodleがファイル送信を確認できるオリジナルIDを送信します。

Maharaサイドでは

待ち行列に入れられたリクエストを処理するための新しいコアcronジョブ

これは、5分ごとにコールされ、関数は「process_incoming_content_queue」または類似のものになります。

MNETの新しい機能

1. portfolio/content_intent - MoodleがMaharaにコンテンツ転送の意思を伝えます。また、必要であればMaharaはユーザを作成して、「no、queonly、queandwait」を返します。

1. portfolio/content_ready - Moodleがエクスポートの一部を終了して、Maharaが取得できるよう、ファイルを準備します。インタラクティブに転送されるかどうかにより、Maharaは次のcronが実行に向けてジョブを待ち行列に入れるか、直接転送を開始します。

新しいデータベーステーブル

content_intentおよびcontent_readyリクエスト間のデータを保存するテーブルが必要です。

テーブルは次のようになります:

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

発送元とアーティファクトプラグインの関係

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.

ターゲットフォーマット

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.

ワークフロー

The more I look into this the more I think the best way to do this is:

1. 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
2. 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.
3. Modify Mahara's land.php to accept an extra parameter to indicate that $wantsurl is relative to Moodle's wwwroot, rather than Mahara's
4. 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?

mnet変更案

This section has moved to Development:MNET_Roadmap

パッケージフォーマット

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

content_readyにバンドルする

Having to store it in a temporary location between receiving it and unpacking the file and using it to create the artefacts

シンプルアプローチ

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)

問題

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.

関連情報

開発:ポートフォリオAPI