「開発:Maharaポートフォリオプラグイン」の版間の差分

2008年11月11日 (火) 02:16時点における最新版

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の新しい機能

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

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関数は、この情報の保存に関して、すでにサポートしていますので、後で追加することは非常に簡単です。

ワークフロー

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

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

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

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

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

mnet変更案

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

パッケージフォーマット

metadata/manifestnのインクルージョンに対するアプローチには、私が考え得る限り、2つの方法があります。ファイルをマニフェスト (xmlまたはtxt) と同時に送信するか、xmlrpcのcontent_readyコールで送信するかです。両者には賛否両論があります。どちらにしても、現在のところ行き過ぎかもしれません。しかし少なくとも、どのようなコンテンツを私たちが持っているか正確に説明するため、マニフェストが必要です (それから、明らかに私たちはZIPファイルを使用する必要があると思います)。

Manifest.xml

このアプローチに関する最大で明らかに弱い部分は、単純にファイルを転送するだけではなく、私たちがフォーマットを定義しなければならないことです。

content_readyにバンドルする

ファイルの受信、ファイルの解凍、解凍したファイルを使用してアーティファクトを作成するため、ファイルを一時的な場所に保存する必要があります。

シンプルアプローチ

私は、manifest.txtで以下のようなことを試してみるかもしれません:

md5sum:format:filename md5sum:format:filename

formatは、FILEまたはLEAPのようになります。

この問題点は、最終的に私たちがLEAPを使用する場合、コンテンツ自体はleap.xmlファイルの中に入り、他のファイルがコンテンツと関連付けられるだけになることです。これは、恐らく次のようにすることで処理できると思います

md5sum:leap:leap.xml

最低限、このようにすることは、複数のファイルを含んだZIPファイルの送信を容易にします (例えば、このステージで非常に考え得ることは、1つの課題に複数ファイルをアップロードすることです)。

問題

理想的には、エクスポートの設定段階で、どのフォルダに転送ファイルを入れるのか等、Moodleがユーザに対して追加的な設定を選択できるようにした方が良いでしょう。しかし、この同じ段階までユーザがエクスポートフォーマットを選択しないため、これは可能ではありません。フィルを自動的にMaharaの「coming」フォルダに入れるか、ユーザにターゲットロケーションを選択させるステップを追加するるか、ここには2つのオプションがあります (これは、フォーマットに関わらず適用されることに留意してください - ネイティブに転送されるブログ投稿は、 (この開発フェーズではなく、将来的に) ユーザがMahara内のターゲットを指定することからメリットを享受できます)。

@@ 1行目: / 1行目: @@
-作成中です - [[利用者:Mitsuhiro Yoshida|Mitsuhiro Yoshida]] 2008年10月21日 (火) 18:05 (CDT)
 ===Moodle - Mahara間における、最初のコミュニケーション===
-ユーザが「Mahara」を選択して、「ポートフォリオにエクスポートする」ボタンをクリックした場合、process_stage_configがコールされる前、最初にプラグインにコントロールを渡すのは、steal_control関数です。
+ユーザがMaharaを選択して、「ポートフォリオにエクスポートする」ボタンをクリックした場合、process_stage_config がコールされる前、最初にプラグインにコントロールを渡すのは、steal_control関数です。
-この時点で、Moodleはユーザに関する必要な情報を提供して、Maharaとの「転送の意図 (intent to transfer)」の通信を試みます。また、Maharaは必要に応じて、ユーザアカウントを作成します。Maharaは次の3つの中からひとつを送り返します - なし、キューのみ、キューおよび即時処理。これは、ユーザが待っている間、転送を実行できるか、キューに入れられた転送がMaharaによって強制されるか指示します。Maharaは、「intent (意図)」エントリをデータベーステーブルに挿入して、Moodleがキューテーブルに保存するIDを戻します。
+この時点で、Moodleはユーザに関する必要な情報を提供して、Maharaとの「転送の意図 (intent to transfer)」の通信を試みます。また、Maharaは必要に応じて、ユーザアカウントを作成します。Maharaは、次の3つの中からひとつを送り返します - 「なし」「キューのみ」「キューおよび即時処理」これは、ユーザが待っている間、転送を実行できるか、キューに入れられた転送がMaharaによって強制されるか指示します。Maharaは「intent (意図)」エントリをデータベーステーブルに挿入して、Moodleがキューテーブルに保存するIDを戻します。
 ===Configセクション===
@@ 12行目: / 10行目: @@
 ===File ready ping (ファイル準備完了ピング)===
-ユーザが転送を承認した場合、ユーザの待つか待たないかの選択に応じて、Moodleはパッケージを起動してステージを送信するか、アイテムをキューに入れるか判断します。基本的に、これらは同じです。両モデルにおいて、Moodleは単に「ファイル準備完了 (file ready)」リクエストをMaharaに送信します。インタラクティブモデルでは、同様にMaharaからの成功レスポンスを待ちます。
+ユーザが転送を承認した場合、ユーザによる「待つ」「待たない」の選択に応じて、Moodleはパッケージを起動してステージを送信するか、アイテムをキューに入れるか判断します。基本的に、これらは同じです。両モデルにおいて、Moodleは単に「ファイル準備完了 (file ready)」リクエストをMaharaに送信します。インタラクティブモデルでは、同様にMaharaからの成功レスポンスを待ちます。
 Maharaが「ファイル準備完了 (file ready)」リクエストを送信する場合、同様に直接HTTP GETリクエスト経由でファイルを取得するためのロケーションをMaharaに送信します。このリクエストの1部として、同様にMaharaはステップ1でMoodleが返してきた、Moodleがファイル送信を確認できるオリジナルIDを送信します。
@@ 24行目: / 22行目: @@
 ====MNETの新しい機能====
-# portfolio/content_intent - MoodleがMaharaにコンテンツ転送の意思を伝えます。また、必要であればMaharaはユーザを作成して、「no、queonly、queandwait」を返します。
+# portfolio/content_intent - MoodleがMaharaにコンテンツ転送意思を伝えます。また、必要であればMaharaはユーザを作成して、「no、queonly、queandwait」を返します。
 # portfolio/content_ready - Moodleがエクスポートの一部を終了して、Maharaが取得できるよう、ファイルを準備します。インタラクティブに転送されるかどうかにより、Maharaは次のcronが実行に向けてジョブを待ち行列に入れるか、直接転送を開始します。
@@ 68行目: / 66行目: @@
 ====発送元とアーティファクトプラグインの関係====
-エクスポートしたフォーマットのリストをインポートできるよう、artefact_pluginベースクラスは、プラグインを必要とするようになります。これは、フォーマット/コンポーネント (例 LEAP/entry または file/file) のようになります。また、複数のプラグインが同じフォーマットをサポートする場合、恐らく優先度 (priority) も保存されます (または、管理者が優先度を設定します)。インポート時、ハンドラーがファイルを展開し、ファイルを適切なアーティファクトプラグインに送ります。
+エクスポートしたフォーマットのリストをインポートできるよう、artefact_pluginベースクラスは、プラグインを必要とするようになります。これは、フォーマット/コンポーネント (例 LEAP/entry または file/file) のようになります。また、複数のプラグインが同じフォーマットをサポートする場合、恐らく優先度 (priority) も保存されます (または、管理者が優先度を設定します)。インポート時、ハンドラがファイルを展開し、ファイルを適切なアーティファクトプラグインに送ります。
 ====ターゲットフォーマット====
@@ 81行目: / 79行目: @@
 # Maharaポートフォリオプラグインがsteal_controlを取得した後、「portfolio/add.php?postcontrol=1」を「$wantsurlget」として、ユーザをMoodleのjump.phpに送ります。
 # Moodleのjump.phpは、ユーザをMaharaのland.phpにリダイレクトします。Maharaでは、SSOセッションをセットアップして、必要であればユーザアカウントを作成します。
-# Modify Mahara's land.php to accept an extra parameter to indicate that $wantsurl is relative to Moodle's wwwroot, rather than Mahara's
+# $wantsurlがMaharaではなく、Moodleのwwwrootと関連していることを知らせるため、Maharaのland.phpが外部パラメータを受け付けるよう修正します。
-# Bounce the user to $wantsurl (which is the portfolio postcontrol url)
+# ユーザを$wantsurl (ポートフォリオpostcontrol URI) に戻します。
-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.
+これは、ユーザがMaharaで認証 (または作成) され、MoodleおよびMahara間を移動するためにコールする必要のあるxmlrpc機能で使用するトークンを私たちが持つことを意味します。
-It does mean that we might have an SSO session where we don't actually need one.
+これは、私たちが実際に必要としないSSOセッションを持っていることを意味するのではありません。
-I'm not sure how this will affect delayed communication between the two systems (eg queued transfers) as the SSO session may have expired?
+SSOセッションの有効期限が切れた? として、これが2システム間で遅延したコミュニケーション (例 キューに入れられた転送) にどのように影響するのか、私には確信が持てません。
 ===mnet変更案===
-This section has moved to [[Development:MNET_Roadmap]]
+このセクションは、[[開発:MNETロードマップ]]に移動しました。
 ===パッケージフォーマット===
-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)
+metadata/manifestnのインクルージョンに対するアプローチには、私が考え得る限り、2つの方法があります。ファイルをマニフェスト (xmlまたはtxt) と同時に送信するか、xmlrpcのcontent_readyコールで送信するかです。両者には賛否両論があります。どちらにしても、現在のところ行き過ぎかもしれません。しかし少なくとも、どのようなコンテンツを私たちが持っているか正確に説明するため、マニフェストが必要です (それから、明らかに私たちはZIPファイルを使用する必要があると思います)。
 ====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:
+私は、manifest.txtで以下のようなことを試してみるかもしれません:
 md5sum:format:filename
 md5sum:format:filename
-where format is something like FILE or LEAP
+formatは、FILEまたは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
+この問題点は、最終的に私たちがLEAPを使用する場合、コンテンツ自体はleap.xmlファイルの中に入り、他のファイルがコンテンツと関連付けられるだけになることです。これは、恐らく次のようにすることで処理できると思います
 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)
+最低限、このようにすることは、複数のファイルを含んだZIPファイルの送信を容易にします (例えば、このステージで非常に考え得ることは、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.
+#理想的には、エクスポートの設定段階で、どのフォルダに転送ファイルを入れるのか等、Moodleがユーザに対して追加的な設定を選択できるようにした方が良いでしょう。しかし、この同じ段階までユーザがエクスポートフォーマットを選択しないため、これは可能ではありません。フィルを自動的にMaharaの「coming」フォルダに入れるか、ユーザにターゲットロケーションを選択させるステップを追加するるか、ここには2つのオプションがあります (これは、フォーマットに関わらず適用されることに留意してください - ネイティブに転送されるブログ投稿は、 (この開発フェーズではなく、将来的に) ユーザがMahara内のターゲットを指定することからメリットを享受できます)。
 ===関連情報===

Documentation