CalDAV を軸とした カレンダの共有を支援するシステムの提案 村田裕哉乃村能成谷口秀夫岡山大学大学院自然科学研究科 DPS155 2013 年 5 月 23 日
No.2 カレンダによる情報共有 カレンダシステムの利用が一般化 Google カレンダー,Yahoo! カレンダー,Apple ical 家族や職場でのスケジュール管理手法 ( カレンダ共有 ): (1) カレンダ情報の送受信 ( 招待機能 ) による共有 (2) グループカレンダによる共有 しかし グループや状況に応じた細かな共有条件の設定が困難 カレンダ共有に適したカレンダの管理方式が必要
既存システムにおけるカレンダ共有 (1) 分散方式カレンダ ( 招待方式 ) 個々の予定情報単位での共有 メールによる予定情報の送受信 他者のカレンダに登録を促す (2) 集中方式カレンダ ( ファミリーカレンダ ) カレンダ丸ごとの単位での共有 メンバが自由に閲覧 ( 編集 ) 可能なグループカレンダ (3) 個人のカレンダを公開 自身のカレンダを他者に閲覧させるのが目的 それぞれ一長一短 : 適切に使い分ける必要 メンバ全員が特徴を理解し適切に使い分けることは難しい No.3
No.4 カレンダ共有の問題点 (1) 分散方式 ( 問題 1) 予定情報の同期の保証が困難 (2) 集中方式 ( 問題 2) 過去の予定情報の喪失 (3) カレンダの公開 ( 問題 3) 目的に応じたカレンダの公開設定が繁雑
No.5 カレンダ共有の問題点 (1) 分散方式 ( 問題 1) 予定情報の同期の保証が困難 (2) 集中方式 ( 問題 2) 過去の予定情報の喪失 (3) カレンダの公開 ( 問題 3) 目的に応じたカレンダの公開設定が繁雑
分散方式カレンダの同期問題 カレンダサーバユーザCの個人用カレンダ ユーザ A の個人用カレンダ (UID:xxyyzz) ユーザ B の個人用カレンダ? (1) 登録? (2) 招待 (2) 招待 ユーザ C ユーザ A ユーザ B A が登録した予定に招待 B, C が予定情報を登録 招待を忘れない? 登録を忘れない? 招待機能を利用できる? 予定の変更があったら? No.6
No.7 分散方式カレンダ :A が予定情報を登録 カレンダサーバユーザCの個人用カレンダ ユーザ A の個人用カレンダ (UID:xxyyzz) ユーザ B の個人用カレンダ (1) 登録 ユーザ C ユーザ A ユーザ B (1) カレンダサーバに予定情報を登録 (UID:xxyyzz) が登録
分散方式カレンダ : 招待メールの送受信 カレンダサーバユーザCの個人用カレンダ ユーザ A の個人用カレンダ (UID:xxyyzz) ユーザ B の個人用カレンダ (2) 招待 (2) 招待 ユーザC ユーザA ユーザB (3) 招待メールを受信 (3) 招待メールを受信 (2) 予定の参加者に招待メールを送信メールの本文 : 予定のタイトルや日時の情報が記載添付ファイル : 予定情報をiCalendar 形式で記述したファイル (3) 招待メールを受信 No.8
分散方式カレンダ :B が予定情報を登録 カレンダサーバユーザCの個人用カレンダ ユーザ A の個人用カレンダ (UID:xxyyzz) ユーザBの個人用カレンダ (UID:xxyyzz) ユーザ C ユーザ A ユーザ B (4) 添付ファイルを用いて登録可能 (4) 添付ファイルを用いてカレンダに予定を登録ユーザ B の個人カレンダに (UID:xxyyzz) が登録 No.9
分散方式カレンダ :C が予定情報を登録 カレンダサーバユーザCの個人用カレンダ (UID:aabbcc) ユーザ A の個人用カレンダ (UID:xxyyzz) ユーザBの個人用カレンダ (UID:xxyyzz) ユーザC (5) 添付ファイルを用いて登録不可能 ユーザ A ユーザ B (5) 添付ファイルを用いて, カレンダに予定を登録不可能招待メールの本文をもとに (UID:aabbcc) を登録 No.10
分散方式カレンダ :A が予定情報を更新 カレンダサーバユーザCの個人用カレンダ (UID:aabbcc) ユーザ A の個人用カレンダ (UID:xxyyzz) ユーザBの個人用カレンダ (UID:xxyyzz) (6) 更新 ユーザ C ユーザ A ユーザ B (6) ユーザ A が予定情報を更新し, 再度招待メールを送信ユーザ B は, 既に登録した予定情報の変更として登録可能ユーザ C は, 手動で予定情報を変更 No.11
No.12 分散方式カレンダにおける問題点 < 分散方式カレンダ> 招待機能を利用し, 個々の予定情報単位で共有するカレンダ (1) 招待機能を利用できないカレンダAPが存在する同期をとるためには, 手動で予定情報の変更する必要がある (2) 被招待者が招待メールをうっかりインポートし忘れる (3) 被招待者が招待メールが分からず, 無視する ( 問題 1) 予定情報の同期の保証が困難
No.13 カレンダ共有の問題点 (1) 分散方式 ( 問題 1) 予定情報の同期の保証が困難 (2) 集中方式 ( 問題 2) 過去の予定情報の喪失 (3) カレンダの公開 ( 問題 3) 目的に応じたカレンダの公開設定が繁雑
No.14 集中方式カレンダのアクセス権を失う問題 個人用カレンダと集中方式カレンダを合わせて利用する場合 カレンダサーバ ユーザ A のカレンダ ユーザ A の個人用カレンダ 友人と飲み会 グループの集中方式カレンダ ミーティング < 集中方式カレンダ> カレンダ丸ごとの単位での共有 メンバが自由に閲覧 ( 編集 ) 可能アクセス権を失うと? ユーザ A
グループ脱退による予定情報の喪失 グループの集中方式カレンダのアクセス権を失う カレンダサーバ カレンダサーバ ユーザ A のカレンダ ユーザ A の個人用カレンダ 友人と飲み会 グループの集中方式カレンダ ミーティング グループの脱退 ユーザ A のカレンダ ユーザ A の個人用カレンダ 友人と飲み会 グループの集中方式カレンダ ミーティング ユーザ A ユーザ A アクセス不可 グループに関わる予定情報が喪失 No.15
集中方式カレンダにおける問題点 < カレンダの役割 > (1) 未来の予定表 (2) 過去の行動履歴 ( 思い出 ) グループの脱退により, 集中方式カレンダへのアクセス権を剥奪 過去の行動履歴が失われる ( 問題 2) 過去の予定情報の喪失 < 過去の予定情報の喪失の是非 > 妥当な場合 : 企業の退職妥当でない場合 : 趣味のサークルから脱退 過去の予定情報を喪失させるか否かを選択可能にしたい No.16
No.17 カレンダ共有の問題点 (1) 分散方式 ( 問題 1) 予定情報の同期の保証が困難 (2) 集中方式 ( 問題 2) 過去の予定情報の喪失 (3) カレンダの公開 ( 問題 3) 目的に応じたカレンダの公開設定が繁雑
目的に応じたカレンダの公開 ユーサ A は と 買い物 をカレンタ に登録 1 つのカレンダを家族と仕事の同僚では見せ方を変えたい ユーザ A のカレンダ 買い物 家族 : : 非公開 買い物 : 公開 仕事の同僚 : : 公開 買い物 : 時間枠のみ公開 ユーザ A No.18
No.19 既存システムにおける目的に応じたカレンダの公開 既存カレンダシステムでは不可能複数のカレンダを用いれば可能だが管理が繁雑 ユーザAのカレンダ買い物 ユーザ A のカレンダ 買い物 ユーザ A のカレンダ 予定有り ユーザ B ( 家族 ) ユーザ A ユーザ C ( 同僚 )
複雑な公開設定の例 (1) 家族には,17 時以前の予定は概略 17 時以降の予定は詳細 (2) 同僚には,17 時以前の予定は詳細 17 時以降の予定は概略 (3) 友人には,17 時以前の予定は非公開 17 時以降の予定は概略 2 2 = 4 通りのカレンダの用意が必要さらに週末と平日を区別したいなどの条件? ( 問題 3) 目的に応じたカレンダの公開設定が繁雑 No.20
仮想カレンダ (VC) を提案 仮想カレンダ VC を実現することでカレンダ共有の問題を解決可能 以下の条件のいずれかを満たすものを VC と定義する ( 条件 1) カレンダである ( 条件 2) VC にフィルタを適用したものである ( 条件 3) 複数の VC を足しあわせたものである 条件 1 を基底とし, 条件 2,3 を再帰的に適用 VC を用いた以下のユースケースにより,VC について考察 (1) グループのカレンダを共有 (2) 個人の予定情報を共有 No.21
ユーザ A のグループ用カレンダ グループのカレンダを共有 ユーザ B のグループ用カレンダ ユーザ C のグループ用カレンダ コードレビュー コードレビュー コードレビュー グループ共有 VC コードレビュー ユーザ A ユーザ B ユーザ C 予定の同期にユーザの手間が不要 過去の予定情報を喪失しない 問題 1 を解決可能 問題 2 を解決可能 No.22
個人の予定情報を共有 ユーザ A の個人カレンダ アルバイト プログラミング方法論 ユーザ B の個人カレンダ サークル活動 応用数学第 1 補講 ユーザ C の個人カレンダ DPS155( 出張 ) 教員会議 個人フィルタ f1 個人フィルタ f2 個人フィルタ f3 グループ共有 VC 私用 ( ユーザ A) 講義 ( ユーザ A) 私用 ( ユーザ B) 講義 ( ユーザ B) 出張 ( ユーザ C) 会議 ( ユーザ C) ユーザ A ユーザ B ユーザ C (1) 1 つのカレンダで複数の見せ方が可能 (2) 時間などの条件でフィルタを適用可能 問題 3 を解決可能 No.23
VC を実現するシステム :HubStar <HubStar> (1) CalDAVによる通信を中継 (2) 既存カレンダを VC として再構成 (3) VCをユーザに提示 カレンダサーバ カレンダサーバ HubStar プロトタイプを作成し,VC が実現可能であることを確認 No.24
まとめ (1) カレンダ共有に関する問題を明確化 ( 問題 1) 予定情報の同期の保証が困難 ( 問題 2) 過去の予定情報の喪失 ( 問題 3) 目的に応じたカレンダの公開設定が繁雑 (2) 仮想カレンダ (VC) を提案 (3) VC の概念を実現するシステムとして HubStar を提案 (4) HubStar のプロトタイプを作成 < 残された課題 > (1) VC に対するアクセス制御の仕組みの考察 (2) HubStar の実装, 評価 No.25
HubStar の処理の流れ HubStar カレンダサーバ キャッシュを更新 キャッシュ (4) キャッシュを参照 (3) 権限を確認 (2) Subscription の詳細を取得 (1) 認証 (5) カレンダ情報を取得 (6) フィルタを適用 (7) ETag を追加 ユーザ No.32