DEIM Forum 2014 C8-5

RMX における拡張プラグイン機構の導入及び各種プラグインの開発
松本 洋平†

北和人†

遠山 元道 ††

† 慶應義塾大学理工学部情報工学科 〒 223–8522 横浜市港北区日吉 3–14–1
E-mail: †{yohei,kita}@db.ics.keio.ac.jp, ††toyama@ics.keio.ac.jp
あらまし ルールベースメール配送システム RMX において, 先行研究では, データベースを利用したメール配送の基
本的な機能が実装されていて, アイディア次第で RMX に様々なアプリケーションを導入できる. しかし, 現在の RMX
では, アプリケーションの機能と RMX 本来のメール配信機能は分離されていないため, 第三者が拡張機能を開発することが困難だった. 本論文では, RMX からメール配送やデータベース情報取得機能以外の機能を切り離し, 拡張機能
をプラグインとして追加する手法を提案した. これらのプラグインは, 本体の RMX とは分離されているため, 本体側の処理に影響を与えない. プラグインの例として, ある特定のイベントへの出席・欠席を管理する拡張機能や, 使用可
能なルール及び各ルールの使い方をメールで確認できる拡張機能などがある.
キーワード

電子メール, RMX

1. は じ め に

2. RMXRMX (Rule-based e-Mail eXchange System) は管理者が設

Rule-based e-Mail eXchange(RMX) は遠山研究室が提案し定したルールを基に，データベースのアクセスを行い，得られている電子メール配信方式である．RMX では下記のような記たユーザ集合に対してメールを配信するメール転送エージェン

述により複数の送信先を指定する. RMX ではアドレスの記述

トである. 先行研究において, アドレスの先頭にコマンドを書方法は標準形式と自然形式の２つがあり，これはそのうち標準

き込むことで, メール配信以外にも様々な機能を使用すること

形式の記述方式を示している．

ができる機能を開発した. しかし, このような機能と RMX 本
体のメール配信機能は分離されていないため, 機能を追加する< RM X のメール配信先指定 >:=ごとに RMX 本体が重くなり, 単体テスト・保守が難しくなる< 配送ルール名 > {< パラメータ >}@ < サブドメイン > . < ドメイという問題があった. また, コマンドによる機能が RMX 本体

ン>から分離されていないため, 第三者が RMX の拡張機能を開発することが困難だった. そこで本論文では, RMX からメール配

RMX のメールアドレスは以上のようにサブドメイン以前を送やデータベース情報取得機能以外の機能を切り離すことで,表す配送範囲記述部分とドメイン部分が”.”の記号で区分され拡張機能をプラグインとして自由に追加できる手法を提案している．配送範囲記述部は一つ以上のパラメータの組み合わせた. これにより, 単体テスト, 保守がしやすくなるだけでなく,で構成され, ”{}”の左側にルール名, 内側にパラメータが記述

Facebook や Twitter などのように, 第三者が拡張機能を安全される．サブドメインは後述する設定ファイルの名前に相当すに開発することが可能となる. また, 本論文ではプラグインのる．RMX はこのような配送範囲記述を受け取る. そして, 指定例として, ユーザ支援プラグインと, イベント管理プラグインのされた配送ルールとそのパラメータに基づきデータベースに問2 つを提案した. ユーザ支援プラグインは, RMX において使用

い合わせを行い実際の送信先アドレスを得る. 最終的に得られできるルール及び各ルールの使い方等の情報をメールの形式でたメールアドレスに基づき配送が行われる.(図 1)

取得することができる機能である. イベント管理プラグインは,

2. 1 配送ルール

同窓会や忘年会などのイベントへの出席・欠席を管理する機能

配送ルールとは配送範囲記述とそれに基づき送信先メールアである. ユーザはメールを送ることで, 自分が出席する, もしくドレスを得るクエリを関連付けるルールである. 配送ルールはは欠席するという情報をデータベース上で更新することができ

以下のように定義する.

る. このデータベースにより, 管理者側は誰が出席か, 欠席かということを知ることが可能となる.
以下，本稿の構成を示す．まず，2 章で RMX の概要について述べる．3 章で拡張プラグイン機構について，4 章でユーザ支援プラグインについて，5 章でイベント管理プラグインについて，6 章で評価について述べ，7 章で結論を述べる．

配送ルール名Type:パラメータの型
query: 送信先メールアドレスを得るためのクエリ
query 部分は SQL によって記述される. RMX は記述された配送ルール名に対応するクエリにパラメータを挿入し, 問い合わせを行うことで送信先メールアドレスの集合を得る. このような配送ルールを用いることにより, 利用者は簡潔な記述で配したい時に用いられる演算子である. 指定された複数の配送"-./0%

ルールの結果の積集合を取り，最終的に得られた結果に対して!"#$#%"-%

配送を行う.
$%&'(%)*+,%例：!"#+$,$%&'()*%

lab{toyama}.grade{1}@rmx.example.edu$%&'-(.(/%+,%$%&'0%12*+,'%

2. 2. 2 和 集 合Syntax: < name1 > {< par1 >}+ ... + < namen >{< parn >}@ < subdomain > . < domain >Semantics: name1 (par1 ) ∪ ... ∪ namen (parn )図 1 RMX におけるメール配信の流れ“+” は，論理和を得たい複数の配送ルール及びパラメータを送範囲を指定することができる. 以下に配送ルール定義の例を指定する際に用いられる. 各パラメータをそれぞれの配送ルー
ルのクエリに代入し, 得られた結果の和集合を取る. そして，最示す.

終的に得られた結果に対して配送を行う.

grade
gradeType= integer
grade[1]= select s.address from student s
where s.grade = $1 ;

次の例は, 同じ grade という配送ルールに複数のパラメータを与えた場合のアドレスである.
例:

grade{3}+grade{4}@rmx.example.edu
上記の例では学年を integer 型で受け取り, それに基づいてメール配信を行う grade ルールを定義している. メールの宛先がgrade{4}@rmx.example.edu の場合，図 2 のように query 部分

また, 異なる配送ルール間で論理和を得る場合を考える．例

で利用者のメールアドレスと学年が格納されている表 student

えば学年が 4 年である，または名前が yohei である学生に対しから, 学年が 4 年の学生のメールアドレスを得るクエリを記述てメールを送ろうとした場合以下のように記述すればよい．
例:

している.

grade{4}+name{yohei}@rmx.example.edu!"#$%&'()"*+,%+#*-.%,%$/!
また，配送ルール間の積集合をとる’.’ と和集合をとる’+’ が同時に使用された場合には，積集合をとる’.’ の方が優先順位が高いものとする．例えば以下の様なメールアドレスが作成された場合，grade と group の積集合をとった後に，その結果とname との和集合をとる．
例：

name{yohei}+grade{4}.group{rmx}@rmx.example.edu

図 2 grade ルールと配送例

2. 2. 3 多相 (ポリモルフィック)
Syntax: < name1 > {< par1 > −...− < parn >}@ <2. 2 複数の配送ルールの組み合わせ (標準形式)

subdomain > . < domain >ここでは，複数の配送ルールを組み合わせてメールを送る

Semantics: name1 (par1 , ..., parn )際に，RMX で使用可能な演算子について説明する. 演算子をEnvelope-To フィールドの配送ルールに使用することにより，ユーザに対してより詳細な配送範囲の指定を可能とする.

2. 2. 1 積 集 合Syntax: < name1 > {< par1 >}. ... . < namen > {<parn >}@ < subdomain > . < domain >Semantics: name1 (par1 ) ∩ ... ∩ namen (parn )“.” は，Envelope-To フィールドに複数の配送ルールを使用“-” は，ポリモルフィックな考え方を導入した１つのルールに複数のパラメータを指定するための演算子である. “-” によって与えられたパラメータの数により配送ルールから呼び出す
クエリが異なる．次の例ではルール name に２つのパラメータ

matsumoto と yohei を与えるため，2 引数の name ルールを使用する．
例：

name{matsumoto-yohei}@rmx.example.edu

以上の３つの演算子は組み合わせて使用することもでき，•

dbPassword = ＜ユーザ ID に対応するパスワード＞

ユーザが配送範囲を指定する際の手助けを行う．メールアドレ
スは以下の形式を取る．

使用するルールの設定もサブドメイン設定ファイルで行う．

3. 拡張プラグイン機構
ListOpe := −3. 1 RMX アーキテクチャ

U nionOpe := +拡張プラグイン機構を実現するために, RMX システムから

RuleOpe := . | + | −メール配送やデータベース情報取得機能以外の機能を排除し,Arg := string | integer

各種レイヤーごと分割する. 各種レイヤーごとの依存関係を小P ara := Arg | Arg ListOpe P ara

さくすることで, 単体テストを容易にし, 保守性・拡張性の高い

P araList := P ara | P ara U nionOpe P araList

システムを構築することが可能となる.

Exp := rule { P araList }ExpList := Exp | Exp RuleOpe ExpList
Address := ExpList @ subdomain . domain例：

name{matsumoto-yohei}.lab{toyama}+name{kita}.
lab{toyama}@rmx.example.edu
2. 3 自然形式アドレス
自然形式アドレスは以下の形式を取る．
< RM X のメール配信先指定 >:=< パラメータ > @ < 配送ルール名 > . < サブドメイン > . < ドメイ

図 3 RMX システムアーキテクチャン>

3. 2 インターフェース設計
自然形式アドレスでは, ”{}”を使用せず, ルール名を”@”の右

上記 RMX システム内に拡張プラグインを読み込み, RMXに書き, 一般的なメール送信で使用されているアドレスと似たの新しい機能として利用できるようなシステムを追加する. こ

形式で RMX のアドレスを記述する.

こでのプラグインは以下のように定義した.

例えば, 学年が 3 年，または 4 年で，名前が yohei である学生
へメールを送る場合の例は以下のようになる．

•

プラグインは RMX システム内でどのように処理されるかどうかは考慮する必要がない•例：

3+4.yohei@grade.name.rmx.example.edu

ファイル化したプラグインを特定のディレクトリに配置するだけで自動的に RMX 内に組み込まれる•ディレクトリ内に複数のプラグインを配置していても,全てのプラグインを認識し, メール内容や状況に応じて使用す2. 4 サブドメイン設定ファイル

るプラグインを切り替えることができる

サブドメイン設定ファイルでは，データベースへの接続や，使用するルールの設定を管理する．ファイル名をサブドメイン

ここでは RMX とプラグインはインターフェースを介して結名.properties とし，.properties の前をサブドメイン名として合される (図 4). RMX 内部には, ”PluginInterface.java”とい使用する．例えば，sample.properties というファイルを作成すうインターフェースが予め用意されており, インターフェース内

れば，サブドメイン sample とすることでこの設定ファイルをに実装したい機能の型 を宣言しておく (図 5). プラグインを作参照し，同様に sample1.properties というファイルを作成し，成する際には, 最初に”PluginInterface.java”を継承したクラス

サブドメインを sample1 とすることでこちらの設定ファイルをを作成し, pluginStart メソッド, getAvailableFunctionNames

参照する．サブドメイン設定ファイルでは以下の項目においてメソッドを再定義する. ここで, プラグイン名を 1 つ設定し,データベース情報を設定する．

getAvailableFunctionNames メソッドで取得できるようにす
る. プラグイン名は, 他のプラグインと重複しないように設定•

dbDriver = ＜データベースドライバ＞する必要がある. また, プラグインに 1 つ, もしくは複数のコ•

dbUrl = ＜接続するデータベースの URL ＞

マンド名を設定しておき, それぞれのコマンドごとに実行する•

dbId = ＜データベース上のユーザ ID ＞

処理を決める. プラグインを使用する際に, プラグイン名とコ

マンド名を指定することで, どのプラグインのどのコマンドを実行するかを判断する. プラグイン名を指定すると, そのプラ

4. ユーザ支援プラグイン

グイン名を持つ”PluginInterface.java”を継承したクラスのイ

RMX は，管理者が指定したルールに基づき，データベース

ンスタンスが生成され, pluginStart メソッドが実行される. こへアクセスを行い，対象となるユーザを見つける作業をサーバの pluginStart メソッドを実行することで, プラグイン内で処上で自動で行う．使用できるルールは設定ファイルの中に記述理が行われ, 最終的に配送するメールが RMX の本体に返されされていて, 編集は管理者が行う. この設定ファイルには使用

る. このクラス内で使用される他のクラスを 1 つの jar ファイ

するデータベースの情報が記述されているため, セキュリティ

ルにまとめることで, 拡張プラグインを作成する. 作成した拡の問題上, 設定ファイルを一般のユーザが閲覧できる状態にす張プラグインの jar ファイルは, 特定のディレクトリに配置することは好ましくない. しかし, 先行研究段階において, 設定ることで, RMX 本体で自動的に読み込まれる.

ファイルを自由に閲覧できない場合, 自分が使用できるルール

この様に, インター フェースを継承したクラスを作成し, 宣言をユーザが知る方法は存在しなかった. また, 使用できるルーされている機能のふるまいを記述することで, メソッド名は同ルの名前を知っていても, それがどのようなルールで, どのようじだが, ふるまいが異なる拡張プラグインを複数作成することに使用すれば良いかという情報を得る方法が無かった. そこでができる. また, RMX 側でプラグインを読み込む際は型及びメ

本論文では, 使用できるルールの名前とその使用方法などの情ソッド名は統一されているので, インターフェース継承により

報をメールの形式で得る手法を提案した.

作成されたプラグインならば, 全てのプラグインを読み込むことができる.

4. 1 機 能 概 要
ユーザ支援プラグインにおけるプラグイン名は”help”で, 以下の様な help コマンドを使用する.

#help.help. < language > #@ < subdomain > . < domain ><language>の部分で, 取得するメールの言語 (en, ja 等) を指定する.
例えば，図 6 のようにメールを送ることで, 各ルールの名前及び関連する情報を指定した言語で取得することができる.
図 4 インターフェース継承によるプラグインの作成!"#$%&'%()*+,-&*'.$"/%(0()*+,-&*'1'''''''''!"#$%&'2++-34%5)'67*55-/*8'!$"/%(9)-+):7*55-/*';+%/%(-$7*55-/*<='''''''''!"#$%&'2++-34%5)'69)+%(/8''/*)2>-%$-#$*?"(&@;(A-B*5:<='
C!

>+'053+'053'$>?.&@3'@%&50'3'A/!

図 5 PluginInterface.java のソースコード>+'053+'053B%>?.&@3'@%&50'3'A/!

3. 3 プラグインの使用方法!"#$%&'()*+,-(./0'(,-(%(1.%$-2'.(./0'3(*+'(145'(62(,1-(5%.%&'1'.(,-(781.,$9:3(;0'%-'(%--,9$(%(/-'.($%&'3(<(!=#9.6/5()*+,-(./0'(,-(%(1.%$-2'.(./0'3(*+'(145'(62(,1-(5%.%&'1'.(,-(781.,$9:3(;0'%-'(%--,9$(%(9.6/5($%&'3<!
!"#$%&'()"#$%$&'($%$)*+,-%.#/&
012345)6789:;<=>?@A"B)*C#8
9:;<>DEF%GH-%$I'(J@K67<(!=#9.6/5()"#$%$&'($%$)*+,-%.#/&
012345)67L$%M=>?@A"B)*C#L$%MNOP6AF%GH-%$I'(J@K67<!

以下の形式のメールを送信することにより, プラグインとして RMX に導入されているアプリケーションの各種コマンドを

図6

ユーザ支援プラグインの使用例

実行することができる.

4. 2 コメントの設定
ユーザ支援プラグインでユーザに提示する情報は, あらかじ# < plugin > . < command > . < arg1 > . … . < argn > # < target >め管理者側が設定しておく. ユーザ支援プラグイン用のプロパ
ティファイルを言語ごとに用意し, その中にユーザに提示した<plugin>では, 使用するプラグインのプラグイン名, <command>
では, 使用するコマンドを記述する. <arg>は, 各コマンドで使い情報をコメントとして記述する. 図 7 の例では, name, groupというルールに対し, それぞれコメントを記述している.

用される引数を表している. 引数の数はコマンドによって異なり, 引数を 1 つも使用しないコマンドも存在する. <target>には, RMX 形式のアドレス, もしくはドメインのみを記述する.

5. イベント管理プラグイン
同窓会や忘年会などのお知らせをメールで行う場合, 一般的には幹事の人がメーリングリスト等を利用し, 招待したい人々へメールを送る. 次に, お知らせのメールを受け取った人々は, 自,#;<)$.3<$!13,43$,=$+!
!"#$%&%'()*+%,-.$%*+%"%/,"!+0$,%,-.$1%()$%/23$%40%*/+%3","#$/$,%*+%56/,*!781%9.$"+$%"++*7!%"%-+$,%!"#$1%:%%
7,4-3%&%'()*+%,-.$%*+%"%/,"!+0$,%,-.$1%()$%/23$%40%*/+%3","#$/$,%*+%56/,*!781%
9.$"+$%"++*7!%"%7,4-3%!"#$1:!

図7,#;<)$.3<>"13,43$,=$+!
!"#$%&%'"#$%$&'($%$)*+,-%.#/&012345)6789:;<=>?
@A"B)*C#89:;<>DEF%GH-%$I'(J@K67:%%
7,4-3%&%'"#$%$&'($%$)*+,-%.#/&012345)67L$%M=>?
@A"B)*C#L$%MNOP6AF%
GH-%$I'(J@K67:!

ユーザ支援プラグイン用のプロパティファイルの設定例•

close コマンドイベントへの参加者の募集を締切る際に使用する.

5. 2 invite コマンド
invite コマンドは, ある特定のイベントへの招待メールを送る際に使用する. 使い方は以下の通りである.

#event.invite. < code > # < rule > {< para >}@ < subdomain >. < domain >分が出席する, もしくは欠席するということを幹事の人にメールで伝える. しかし, この方法では幹事が招待者からのメール<code>の部分には, event テーブル内の属性”code”の値が入る.

を見て, 誰が出席, もしくは欠席であるかを記録しておく必要が

この<code>により, どのイベントの招待メールであるかを識別ある. また, 出席者のみにメールを送りたい場合, 欠席者のみにする. invite コマンドを使用すると, メールが送られたメンバー

メールを送りたい場合など, 送り先を限定することが困難であの id と, 対応するイベントの id が attend テーブルに挿入される. そこで本論文では, メールを送ることでデータベースを更る. attend テーブルにより, 誰がどのイベントに招待されてい新し, 誰が出席か, もしくは欠席かという情報をデータベース上るかという情報を管理することが可能となる.

で管理できる機能をイベント管理プラグインとして提案した.

例えば, ”遠山研究室”という研究室に所属しているメンバーに対し, ”2014 年 OB 会”というイベントへの招待メールを送りた

5. 1 機 能 概 要

い場合は, メールアドレスの表記は以下のようになる.

イベント管理プラグインでは, member テーブル, attend テー

例:ブル, event テーブルの 3 つを使用する (図 8).

!"!#"$!"#$%#event.invite.ob2014#lab{toyama}@rmx.example.edu%&"'(!"#$%

5. 3 attend/absent コマンド
attend コマンド, absent コマンドは, イベントに招待された人が出席・もしくは欠席の通知を行う際に使用する. 使い方は以下の通りである.
")"'*!"#$%#event.attend. < code > #@ < subdomain > . < domain >#event.absent. < code > #@ < subdomain > . < domain >図 8 イベント管理プラグインで使用するテーブル<code>の部分で, どのイベントに対してコマンドを使用しているかを識別する. attend/absent コマンドを使用すると, attend

member テーブルには各ユーザの情報, event テーブルにはテーブル内の属性”status”の値が”attend”, もしくは”absent”

各イベントの情報を格納する. attend テーブルには, 招待さに更新される. このコマンドは, event テーブル内の対応するイれたユーザの id と, 招待したイベントの id を格納すること

ベントの属性”update”が”true”の間のみ使用可能である.

で, 誰がどのイベントに招待されているかを記録する. また,

例えば, ”2014 年 OB 会”というイベントへの出席の連絡をする”status”という属性には, それぞれのユーザが出席 (attend), 欠場合は, メールアドレスの表記は以下のようになる.

席 (absent), または未定 (uncertain) であるかという情報を格

例:

納する.

#event.attend.ob2014#@rmx.example.edu

イベント管理プラグインにおけるプラグイン名は”event”で,使用できるコマンドは主に以下の 4 種類である.

•

invite コマンド

招待メールを送る際に使用する.

•

5. 4 send コマンド
send コマンドは, 招待した人々にお知らせを送る場合に使用する. 使い方は以下の通りである.

attend/absent コマンド招待された人が, 自分が出席するか, もしくは欠席するかを伝え#event.send. < code > #@ < subdomain >.< domain >る際に使用する.

•

send コマンド<code>を指定することで, そのイベントに招待されている人々

招待されている人々にメールを送る際に使用する. 出席者だけ全員にメールを送ることができる.

にメールを送る等, 送り先を限定することも可能.

send コマンドでは, 引数をもう 1 つ記述することで, 出席者, 欠

表2

席者, 未定の人等, 特定の人々に限定してメールを送ることも可

共通部分を除く各プラグインのコード量

能である.

#event.send.<code> . <status>#@<subdomain > . < domain >プラグイン名

コード量

ユーザ支援プラグイン

116 行

イベント管理プラグイン

539 行<status>の 部 分 は, ”attend”(出 席 者), ”absent”(欠 席 者),
行のコードを書く必要はなく, 表 2 の様に, 比較的少ない量の”uncertain”(未定) のいずれかが入る.
例えば, ”2014 年 OB 会”への出席・欠席が未定の人に対し, 連

コードを書けば良い.

絡を催促するメールを送る場合は, メールアドレスの表記は以

6. 2 イベント管理プラグインにおける評価実験

下のようになる.

研究室の OB 会を想定し, 被験者 5 人にはイベントの幹事として, 出席予定, 欠席予定, 未定の人に対してメールを作成して例:もらう. メールの作成は, 通常の方法と, イベント管理プラグ#event.send.ob2014.uncertain#@rmx.example.edu

インの send コマンドを使用する方法の 2 通りで行ってもらう.
イベントに招待される人数は 5 人, 10 人, 15 人の 3 通りの場合
で行ってもらう. 招待された人は, 未定の場合を除き, 幹事に出

5. 5 close コマンド
close コマンドは, 特定のイベントの参加者募集を締め切る際

席・欠席を通常のメールで伝えていて, イベント管理プラグイ
ンの attend テーブルでも出席・欠席の情報を更新しているもに使用する. 使い方は以下の通りである.

のとする.

#event.close. < code > #@ < subdomain > . < domain >このコマンドを使用すると, 対応するイベントの属性”update”

メールは, 出席予定の人は図 9, 欠席予定の人は図 10, 未定の人は図 11 を送る.

の値が”false”に更新され, このイベントに対して attend/absent
コマンドが使用できなくなる.

件名: 2014 年 OB 会へ出席される皆様

例えば, ”2014 年 OB 会”の参加者募集を締め切る場合は, メー

本文:

ルアドレスの表記は以下のようになる.

2014 年 OB 会へ出席される皆様, 遠山研 OB 会担当の例:◯◯です.OB 会の開始時間を 17 時とお知らせしていましたが, 18 時に変更になりました.

#event.close.ob2014#@rmx.example.edu

申し訳ありませんが, よろしくお願いします.

図 9 出席予定の人に対するメール

6. 評

価

6. 1 コード量による評価
各プラグインのコード量による評価を行った. まず, 各プラ

件名: 2014 年 OB 会を欠席される皆様
本文:

グインで共通するファイルのコード量は表 1 の通りになり, 合2014 年 OB 会を欠席される皆様, 遠山研 OB 会担当の計すると 1578 行となった.

◯◯です. ご連絡ありがとうございました.
次回の OB 会には是非ご参加ください.
今後もよろしくお願いします.

表 1 各プラグインで共通するファイルのコード量
ファイル名

コード量

DatabaseDao.java

82 行

図 10

欠席予定の人に対するメール

GetMailAddressesFromDBService.java

31 行

ParseOf1stFormService.java567 行

件名: 2014 年 OB 会への出席が未定の皆様

ParseOf2ndFormService.java

667 行

本文:

ParseService.java

231 行

2014 年 OB 会への出席が未定の皆様, 遠山研 OB 会担当の◯◯です. 出席のご連絡は明日まで受け付けていますので,是非ご参加ください. よろしくお願いします.

次に, 共通部分を除いた, 各プラグイン固有のコード量は表 2の通りになった.
今後, 新たな拡張プラグインを開発する際は, 共通部分の 1578

図 11

未定の人に対するメール

イベント管理プラグインを用いる方法では, 以下の 3 つのア

人々へメールを送る場合, 送り先の抽出に時間がかかり, 最終的ドレスに対してメールを送る.

なメールの作成時間が他よりも長くなる傾向が見られた.

#event.send.ob2014.attend#@testy.rmxdev.db.ics.keio.ac.jp#event.send.ob2014.absent#@testy.rmxdev.db.ics.keio.ac.jp#event.send.ob2014.uncertain#@testy.rmxdev.db.ics.keio.ac.jp

一方, イベント管理プラグインを使用した場合, 招待人数, 送り
先がどの場合でも, 作成時間はほぼ一定であった. send コマン
ドを使用した場合, 送信者側が出席・欠席・未定の人々を抽出する作業を省くことができる. そのため, 招待人数や送り先が実験の結果, 出席予定の人に対するメールの作成時間は図 12,

変化しても, メールの作成時間に影響がなかったと考えられる.

欠席予定の人に対するメールの作成時間は図 13, 未定の人に対これらの事から, 招待する人数が多いほど, イベント管理プラグ

するメールの作成時間は図 14 の様になった.

インが有用であると考えられる.

7. お わ り に!"#$%&'!(")

%#!"
%!!"

本研究では，RMX の構造を見直し, RMX における拡張プラ$#!"

グイン機構の導入, 拡張プラグインの例として, ユーザ支援プラ$!!"

67389)

グイン, イベント管理プラグインの提案を行った.

:;<=>?@AB:<)

拡張プラグイン機構を導入することで, 第三者が拡張機能を開#!"発できるようになり, RMX で使用したい機能を管理者自身が
!"
#"

$!"

決定することが可能となった.

$#"*+,-./01"2345!4")また，ユーザ支援プラグインでは, 使用できるルールの名前及び使用方法などの情報をメールの形式で取得できるようになり,

図 12 出席予定の人に対するメールの作成時間

実際に自分が使用できるルールを知らないユーザを支援することが可能となった.
また, イベント管理プラグインでは, イベントへの招待, 出席・%!!"!"#$%&'!("#

欠席の管理等をデータベースを利用して管理することが可能と
なった.

$#!"

$!!"

672895:;<=>?@AB:<5

#!"

!"
#"

$!"

$#"

)*+,-./0"1234!3"

5

文
図 13 欠席予定の人に対するメールの作成時間!"#$%&'(!)"*

&#!"
&!!"
%#!"
%!!"
$#!"

67$89*$!!":;<=>?@AB:<*

#!"
!"
#"

$!"

$#"

+,-./012"3$45!4"*

図 14 未定の人に対するメールの作成時間

従来の方式でメールを作成した場合, 招待した人数が増える
につれて, メールの作成時間が増加した. 従来の方式でメールを作成する場合, 招待した人々からのメールを読み, 誰が出席か,もしくは欠席かを確認する必要があるため, 人数が増えること
で作成時間が増加したと考えられる. また, 出席・欠席が未定の

献[1] 高畑 理, 藤沼 健太郎, 石橋 玲, 遠山 元道. ”Magic Mirror Mailing：個人情報データベースを利用する柔軟なメイル配送システム”, 情報処理学会データベースシステム研究報告 Pages:123-128
July 2001[2] Kim Hanki, Sang-Gyu Shin, Motomichi Toyama. ”A RuleBased Mailing System for an Organization”, International
Workshop on INformation Processing over Evolving Networks, June 2006
[3] 原田 哲志, 慎 祥揆, 遠山 元道.”RMX における電子メール送受
信範囲管理方式の提案”, DBWS2007[4] 青山 陽亮, 遠山 元道.”RMX におけるポリモルフィックルールとメール本文編集機能の導入”, DEIM2010[5] 北囿 達也, 青山 陽亮, 遠山 元道.” RMX における関数形式アドレスおよびデバッグ支援機能の実装”, DEIM2011[6] 小船井 寛, 青山 陽亮, 北囿 達也, 遠山 元道. ” RMX におけるルール軍管理機構・エイリアス機構等の実装”, DEIM2012[7] 松澤 慧, 北囿 達也, 小船井 寛, 遠山 元道. ” RMX における受信者別メール本文生成機能および本文参照型アドレスの実装”,
DEIM2013[8] Luca Cardelli, Peter Wegner, ”On Understanding Types,
Data Abstraction, and Polymorphism”, In Computing Surveys, Vol 17 n. 4, December 1985, pp.471-522[9] Raphael M. Reischuk, Michael Backes, Johannes Gehrke,”SAFE Extensibility for Data-Driven Web Applications”,
In WWW ’12 Proceedings of the 21st international conference on World Wide Web Pages 799-808