AclのDAOのテストケースを書き終わった。

昨日は別件で、日中、都内で別の作業をしていた。終わってから家に戻り、夜、AclのDAOのテストケースを書き始めた。
気晴らしに東方風神録で、EASYモードで霊夢と魔理沙を2モードほどクリア。まだNORMALは無理ぽ。EASY制覇をまず目指す。
で、今日は起きてからまたAclのDAOのテストケースを書いてて、今終わったのだ。

というか、かなり迷った。ACL自体の可視・不可視はどうする？という問題が出てきたからだ。例えば、ユーザーＡの作成したACLは、ユーザーＢにも無条件に見えてしまって（つまり、ユーザーＢが記事を書くときにACLとして選択できて）よいのか。
で、昨日の夜の最初の頃は、「うーん・・・可視・不可視・・・というよりは、PublicかPrivateかあった方が良いなぁ・・・」と思って、それようのカラムをテストデータファイルに入れていた。

のだけれど。

果たしてそこまでする必要はあるのか？と。

0.0.1が目指すのはあくまでも個人が、個人の（例えばレンタルサーバなどの）スペースに入れるシンプルなツールである。
まぁ、PHPやLinuxに詳しい管理者がいれば、数十人程度くらいまでの会社であれば文書共有とかにも使えるだろうけれども。
そうした時、どんなACLが作成されるか？

個人であれば、例えば「秘密の日記」「友達専用」「家族専用」「サイクリング仲間向け」「会社仲間向け」みたいな感じになる。
会社であれば、例えば「全社員向け」「管理者専用」「社長以上」「部長以上」「課長以上」「総務からのお知らせ」みたいな感じになるだろう。・・・これ、わざわざ可視・不可視を制御する必要があるモノなのか？

ユーザーＡが0.0.1のYakiBikiを公開利用していたとしよう。そこにユーザーＢがログインしてくる。ユーザーＢは何かしら記事を作ろうとする。ここで、記事のACLの選択肢に・・・何が表示されるべきだろうか？
ユーザーＢがログインしているYakiBikiは、ユーザーＡの所有物なのだ。従って、ユーザーＡがそこで作成される記事に対するACLを制御できるのは当然として、さて、他のユーザーにまでACLの制御を許可する必要はあるのか？
例えばここでユーザーＢが「友達専用」のACLを選択したとしよう。それは何を意図したものか？そのYakiBikiのオーナーであるユーザーＡにとっての「友達専用」にしたいからそうしたのだ。というより、多分そうするだろう。
逆にユーザーＢが、間違って「秘密の日記」のACLを選択したとしよう。これは意図とは違ったとする。しかし、ではユーザーＢには見えなくなるのか・・・というとそんなことは無い。「秘密の日記」にユーザーＢのREADが禁止されていたとしても、記事の作成者であれば必ずREAD/WRITEが与えられるからだ。というよりは与える。でないと、直せない。ユーザーＢは間違いに気づいた後、ユーザーＡの用意した別のACLに直せばよい。
では、ユーザーＢが「悪意を以て」ユーザーＡに不都合な情報を「インターネット公開」みたいなACLに設定した場合はどうなるか？
これはあまり・・・悪意の実行手法としては有効等は言えない。が、たとえばユーザーＡのYakiBikiを見に来ているその他の常連ユーザーに対して、ユーザーＡのブランドイメージを低下させる効果はあるだろう。
別のパターンとして、同じく悪意を以て、常連ユーザーの一人であるユーザーＣに不都合な情報を同様なACLに設定した場合は？
・・・これは敷衍すると、現行でも例えばBlogなどに、特定個人を誹謗中傷するような記事を載せる・コメント、トラックバックを打つ、などと同等に思える。まぁ、多分。では現行、そうなった場合どうするか？
単純に、ブログのオーナーが適宜コメントやTBを削除し、自身の意見を表明して取り仕切る。失敗すれば炎上するだろう。
つまりサイトの所有者の責任となる。
・・・変わらないよな。ユーザーＢが「悪意をもって」した事に対する措置は、当然サイトの所有者であるユーザーＡが取り仕切るべきだろう。ACLを変えるなり、記事自体を削除するなりして、関係各位へ意見を伝え、自体の沈静化を図る。
この一連の根本的な原則、「関係当事者達が頭を使って問題解決を図る」というのは、YakiBiki0.0.1が企業で使われようと変わることはない。

YakiBikiは自分一人の頭でひねり出されるものだが（少なくとも0.0.1に関してはそうだ）、YakiBikiの利用者は、自分より遙かに頭の良い人間もいるだろうし、自分では思いもつかない使い方で上手く運営してくれる人もいるかもしれない。
多数の人間の中には、自分より頭の良い人間が沢山いるはずである。

よろしい。答えは見えてきた。ACL自体にそうしたユーザー・グループを意識した可視・不可視制御は付ける必要はない。あるサイトに登録されているACLは、サイトのログインメンバーであれば記事を書くとき、全てを選択可能とする。とりあえず今のところは。
過失或いは故意により、ACLのそうした性質が原因でトラブルが発生した場合は、サイトのオーナーと関係当事者間の問題調整・解決能力を信じる。

自分一人が頭を捻ったシステムで、そうした全く未知の運用・運営問題に対処できるなんて。無理。

というわけで、今回のコンセプト。
「迷うような機能は後回し！！なぁに、ユーザーの方で上手くフォローしてくれるさ！！きっと！！」

と言う感じで、テストデータも込みで作り終わり。明日か明後日には、実装できると良いなぁ。
で、あと、問題になるのは速度。と、実際のYakiBiki Data Object(Wikiとか画像とか添付ファイルとか)とのACLの物理的な繋げ方、とか、リスト表示時のキャッシュ機構とか。
まぁ、まだ後回しでも問題ない。
なぁに、Cache_Liteでごまかせるさ！きっと！！

・・・というか、daoレベルでそこまで作り込む必要は無いんじゃないかな。と思ふ。ここでも後回しの原則。