はじめに
コンテキストの共有化をマルチクライアントで実現する仕組みが稼働します。つまり、同一のページを複数のクライアントで参照しているとき、誰かがデータを変更すると、その結果は他のユーザのページにも反映されるという動作が典型的です。従って、1つのフィールドを単一の要素にバインドしている場合でも、マルチユーザつまり複数のブラウザで同一のエンティティをバインドしているという点で「共有化」されていると言えるわけです。コンテキストの共有化を実現するために、ページファイル上でのターゲット指定や、定義ファイルでのコンテキスト定義以外に何をしなければならないかをこの文書にまとめておきます。なお、このページに記載の内容は、Ver.5まで適用できます。Ver.6ではこの機能を廃止、Ver.7以降で別の実装に移行します。
機能の概要と実現手法
INTER-Mediatorでは、「コンテキスト」は、データベースに対するデータの出入り口的なイメージのものであり、検索条件などでの意味づけされたデータソースを意味します。その「共有化」とは、同一エンティティが複数のページ上のオブジェクトに展開されているとき、1つのエンティティを変更すると、その結果が他のオブジェクトにも反映される仕組みと定義します。Ver.4.4までに、単一ページ内のコンテキストの共有化が実現しています。つまり、あるページ上に、同一フィールドとバインドした要素があるとすると、一方を変更すると、もう一方は自動的に更新します。この動作を実現するためのプログラミングは必要なく、バインドの設定（ターゲット指定の付与）だけで可能です。しかしながら、マルチクライアントでのコンテキストの共有化では、WebRTCを利用したPusherというサービスを利用することにしました。試用程度なら無償ですが、実運用には有償となってしまうものの、開発の効率化のために利用することにしました。
Pusherアカウントの取得とアプリケーション登録
Pusherのサイトでアカウントを取得します。Pusherでは「App」という単位で管理ができるので、たとえばINTER-Mediatorで作る1つのソリューションを、1つのPusherのAppとして登録するという方法もありますし、複数のソリューションで共有してもいいかもしれません。いずれにしても、アカウントを作成し、New Appというボタンなどで新たに1つのAppを作成します。ページ上に表示されるapp_id、key、secretの3つの情報がこの後に必要となります。
Pusherのサーバープログラムのインストール
PusherのサーバーモジュールはPHP版を利用します。こちらのレポジトリをダウンロードし、そこから得られるlibディレクトリにあるPusher.phpという1つのファイルだけをサーバーにインストールします。他は使用しません。ファイルはPHPの設定ファイル（php.iniが代表的）で、include_pathの設定で参照できるディレクトリにあればかまいません。もっとも安直な方法は、INTER-Mediatorフォルダに入れて、サーバーにコピーしておくことです。もし、設定が以下のようなものであれば、例えば/usr/lib/phpディレクトリにPusher.phpをコピーしておけば良いでしょう。
include_path = ".:/usr/lib/php/pear:/usr/lib/php"
ページファイルへの追加
Pusherのクライアントソフトウエアを、ページファイルで組み込む必要があります。たとえば、以下のように、ヘッダ部で定義ファイル（include_MySQL.php）の読み込みの前に読み込みます。この方法だと、Pusherのサイトから直接取り出すので、ファイルを自分のサーバーにコピーする必要はありません。ソースはこの通りコピペで大丈夫ですが、Pusherのバージョンが変わった時などはそれに合わせてください。
<html>
<head>
:
<script src="http://js.pusher.com/2.2/pusher.min.js" type="text/javascript"></script>
<script type="text/javascript" src="include_MySQL.php"></script>
</head>定義ファイルあるいはparams.phpへの追加
Pusherで定義したAppに関する指定は、定義ファイルのオプション部あるいはparams.phpで指定をします。原則的にはどちらか一方で定義をしてください。両方指定すると、定義ファイルの方が優先されます。定義ファイルでは、pusherをキーにした配列を定義し、さらにPusherのAppで示された3つの値を配列の各要素の値とします。以下は、定義ファイルでの定義例です。
IM_Entry(
array(
/* コンテキストの定義 */
),
array(
:
'pusher' => array(
'app_id' => '1234',
'key' => '9876543210',
'secret' => '9876543210',
),
),
array('db-class' => 'PDO'),
false
);params.phpファイルに記述するときには、以下のように、$pusherParameters変数に同様な配列として定義をします。
$pusherParameters = array(
'app_id' => '1234',
'key' => '9876543210',
'secret' => '9876543210',
);上記のいずれかがあると、マルチクライアントのコンテキストの共有化がオンになります。定義ファイルあるいはparams.phpの指定の有無だけで、共有化の利用／不使用が決まります。指定がないと一切何も行いません。指定があるのに、Pusherのサーバーあるいはクライアントソフトウエアが利用できない状態になると、なんらかのエラーが発生します。
Ver.4.6での制約
レコードの追加においては、そのコンテキストの検索条件を加味して、検索条件に合わないレコードの追加は行いません。しかしながら、別のクライアントで作成したレコードが当初はコンテキストに合わないものの、フィールドの値を変更してコンテキストの検索条件に合うようになっても、現状ではそのレコードが見えるようにはなりません。
さらに、コンテキストのソート条件は現状では加味されておらず、一連の表示リストのサイトに常に追加されます。