開発: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リクエスト間のデータを保存するテーブルが必要です。

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

フィールド	データタイプ	コメント
id	integer	連続する数値です。content_intentピングの後、Moodleに送り返されます。
host	char(255)	hostテーブルのfk (Foreign Key 外部キー) です。
timestamp	timestamp	初期content_intentピングのタイムスタンプ (または、有効期限フィールド) です。
userid	integer	usrテーブルのfk (Foreign Key 外部キー) です。
queue	boolean	このファイルをcronjobがピックアップするかどうか指定します。
ready	boolean	このファイルをMoodleがピックアップする準備ができているかどうか設定します。

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

エクスポートしたフォーマットのリストをインポートできるよう、artefact_pluginベースクラスは、プラグインを必要とするようになります。これは、フォーマット/コンポーネント (例 LEAP/entry または file/file) のようになります。また、複数のプラグインが同じフォーマットをサポートする場合、恐らく優先度 (priority) も保存されます (または、管理者が優先度を設定します)。インポート時、ハンドラーがファイルを展開し、ファイルを適切なアーティファクトプラグインに送ります。

ターゲットフォーマット

Nigel (Mahara開発リーダー) と私 (Penny) は、ユーザがMahara内でコンテンツを選択するオプションを与えられることに関して、数多くのアイディアを議論しました。最終的に私たちは、ファイルプラグインの「incoming」エリアにファイルを置くという、ファイル転送のみサポートすることに決定しました。後で、ユーザがターゲットを選択できるよう、Moodle内のMaharaプラグインからMahara内の特別ページにリダイレクトすることができます。 私たちはターゲットをmnetプロトコルの一部にすることに関して議論しました。しかし、この機能に関して、上手くユーザに提供することをMoodleに対して (Moodle内のMaharaプラグインにでさえ) 期待するには、潜在的に複雑過ぎます。この時点で、ユーザはMaharaにリダイレクトされます。すでに私たちは「content_intent」ピングを受信しているので、この情報をMaharaに保存して、後でコンテンツを解凍するときに使用します。Moodleでは、このことを知る必要さえありません。ポートフォリオAPIのsteal_control関数は、この情報の保存に関して、すでにサポートしていますので、後で追加することは非常に簡単です。

ワークフロー

このドキュメントを読むたびに、私は以下の方法がベストだと思うようになりました:

1. Maharaポートフォリオプラグインがsteal_controlを取得した後、「portfolio/add.php?postcontrol=1」を「$wantsurlget」として、ユーザをMoodleのjump.phpに送ります。
2. Moodleのjump.phpは、ユーザをMaharaのland.phpにリダイレクトします。Maharaでは、SSOセッションをセットアップして、必要であればユーザアカウントを作成します。
3. $wantsurlがMaharaではなく、Moodleのwwwrootと関連していることを知らせるため、Maharaのland.phpが外部パラメータを受け付けるよう修正します。
4. ユーザを$wantsurl (ポートフォリオpostcontrol URI) に戻します。

これは、ユーザがMaharaで認証 (または作成) され、MoodleおよびMahara間を移動するためにコールする必要のあるxmlrpc機能で使用するトークンを私たちが持つことを意味します。

これは、私たちが実際に必要としないSSOセッションを持っていることを意味するのではありません。

SSOセッションの有効期限が切れた? として、これが2システム間で遅延したコミュニケーション (例 キューに入れられた転送) にどのように影響するのか、私には確信が持てません。

mnet変更案

このセクションは、開発:MNETロードマップに移動しました。

パッケージフォーマット

metadata/manifestnのインクルージョンに対するアプローチには、私が考え得る限り、2つの方法があります。ファイルをマニフェスト (xmlまたはtxt) と同時に送信するか、xmlrpcのcontent_readyコールで送信するかです。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