N.Katoh
typer_jp****@yahoo*****
2005年 4月 2日 (土) 20:11:56 JST
加藤です。件名をかえました。 まず始めに私の考えを書いておきます。 - IDの管理は永続化レイヤの仕事で形式は永続化レイヤが決める - IDを使う／使える範囲は議論の余地あり。 -- cgi内部で止め、ユーザには認識させないか？ -- URLに使う事を認めるか？ -- 永続化レイヤ内に止めるのなら3.*にも導入可能 On Sat, 02 Apr 2005 15:03:24 +0900 ISHIDA Naoto <not20****@anet*****> wrote: > いしだなおとです。 > > 以下では手を抜いて複数のメッセージに返信してます。 > それと何度か下書きして書いたのですが前後のつながりが分かりにくいかも知 > れません。ご容赦を。 > > >「IDとページ名がかぶらないようにする必要がある」というのは永続化レイ > >ヤの話ですが、これは、 > > >・IDは内部管理 & 恒久的URL用 > > 永続化レイヤというのはファイルシステム上のファイル名ですよね。これとペ > ージ名は独立させたほうが良いのは、共通の認識になってきているようですね > 。 > > たけぞうさんも仰ってましたが、この永続化レイヤにおけるID（仮にページ > IDとでも呼びましょうか）を表面に出す必要は必ずしもないでしょう。 > Wikiの外の世界からあるページにリンクするURLを示すもの（Permalinkです。 > 恒久的URL用と同義）は別にあってもいいと私は考えています。 あとで出る竹添さんがいまいちと思った事がこの考えにつながると思います。私 は竹添さんの考えを、「恒久的URLとしてなら自分で付けた意味ある英字のペー ジ名を使いたい」と読みとりましたが、いかがですか？＞竹添さん > > よく考えたら、これまでのURLでもIDでもアクセスできるようにするのは > > いいのですが、日本語ページ名だと > > > > wiki.cgi?page=URLエンコードされたページ名 > > wiki.cgi?page=ID > > > > でしかアクセスできないということになりますよね。で、IDは今のところ > > シーケンシャルなIDを振ることを考えています。自分で言っておいてなん > > ですが、これはちょっと今いちかなぁという気がします。 > > ここで仰られている「ちょっと今いち」と感じる部分を具体的にすることがで > きると、逆にどうすればよいかが見えてくるかもしれません。 > 単にシーケンシャルなIDを全否定されると、論を進めづらくなってしまう気が > します。 この時の前提はタイトル＝ページ名で短いURLを実現しようと思うと、 - 日本語ページ名＝日本語タイトルではなく英字ページ名＝英字タイトルにしな くてはならない - もしくは関連性が全くないIDを使用しなくてはならない といった意味で「いまいち」だと。そこでタイトルとページ名を独立にし、 - リンクはわかりやすい英字ページ名 - タイトルはわかりやすい日本語タイトル を実現できれば解決する。そうするとIDを表に出す意味はないかも？と、なった のでは？ ちょっと前後します。 > ユーザにとってはページの内容（コンテンツ）が主眼であり、それを指し示す > ものとしてページ名があるわけです。そのうえIDまで意識しなければならない > となると使い勝手は低いかと思われます。 > > 「IDも使える」というのは「IDが使われることがある」ということですから、 > 結局はユーザがIDを意識せざるを得なくなります。始めから、「IDはユーザが > 意識しなくても良いもの」という前提をもって作るといいのではないでしょう > か。 > > iノードやページIDの概念が有効であると言うのとは別次元の話です。否定し > ているわけではないので、その点は申し添えておきます。 たしかにページIDをユーザが意識しなければならないのは本末転倒ですね。 ページIDをcgiの外に出すか出さないかは議論の余地がありそうです。 そこで、 - ユーザはページIDを使わなくとも何ら困ることはない様にする。 （ページIDを使って実現できることは使わなくても実現できる様にする） というのを大前提にし、「IDだとこういうことが出来る」というものがあれば、 「IDを使わずに実現するにはどうすれば良いか？」を考えた上で両者を比較検討 すると良いのかも知れません。 たとえば - 短いURLが良いが、わざわざ英字ページ名を付けるのは面倒な人のためにペー ジIDで代用できるようにする。（外部からのリンク用が前提、wiki内で使うの なら日本語ページ名でもなんら問題ないと思う） なら、 - ページIDを使わなくて良い様にするためには、英字ページ名を＊後で加える＊、 つまりエイリアス機能を付ける。 - エイリアス機能をもう1歩進めて、元のページ名も後で付けたページ名も同等 として扱う（つまりハードリンク相当） が考えられますね。そして両者を比べると、 - ものぐざな人には後（その場）で付けるのも面倒。IDが使えた方が便利？ - エイリアスが乱立すると収拾がつかなくなりそう？ - wiki内でIDが使われるとwikiのわかりやすさが損なわれる。 →wiki内ではIDを使えなくても問題内のでは？ 等々、いかがですか？＞みなさん ここまではIDを適用すべき範囲についてでした。 次にIDの形式について。 > 一般に人はランダムな文字列を認識するのは苦手ですが、たとえば「4桁の数 > 字」程度なら、覚えやすいものとしてさまざまなものに使われていると思いま > す。 > ：省略 > > > で、2つの案の違いはIDが表面に出てくるかどうかというところです。 > > この部分は前記の疑問（いまいち）とつながっているんですよね。 > > その疑問に対する私の考えを書いてみます。 > ・ランダムな英数字や記号が13文字 > ・単純なインクリメンタルの数字 > のようなものは、使いたくないと考えます。1つ目のほうは、人によっては6文 > 字でさえもNGかもしれませんね。 3文字ならいかがでしょうか？私も計算して驚いたのですが(^^; [A-Za-z0-9]の62文字 ** 3文字（3乗） = 238,328ページ 十分でしょう。 > 単純なインクリメンタルの数字が悪いのは、UI以前の問題で、spamのような絨 > 毯攻撃に晒されやすいであるとか、新規ページ作成での衝突が起こりやすいと > いう技術的な問題です。 たしかにそうかも知れません。あと、面白くない（ぉ ただ、（関連のない）次のページを見るというユーザの楽しみが生まれます:-) > ここで提案したいのが、次のような方法です。 > > 前提 > 内部だけで使われるID（ページID）に関してはもっと別に冗長な方法をとって > もいいと思っています。 > 以下の案はPermalinkで用いるための識別子です。 > > ・0000〜9999までの1万個要素をもつ数列を、ひとつのまとまりとする > ・この数列をランダムな順で並べ、それをIDとして使う > ・ランダムな4桁数字を生成→コリジョン検出→衝突したら再生成、など > をAPI化 このID新規生成のAPIですが、最初に述べた通り永続化レイヤの仕事と考えてい ます。そして、4.*では、出来れば数種のバックエンド（ファイルシステム、 RDBM、CVSも面白い）をもつ永続化レイヤをサポートしたいところ。 そうすると、それぞれのバックエンドで付けやすいIDが存在する気がします。 ファイルシステムだとmktempがあります。RDBMは詳しくないですが、Accessは シーケンシャルもしくはランダムなIDを自動的にふることが出来ますね。他の RDBMもそういったID生成機能はありそうです。この場合、使用できる文字の限 定はあまりしない方がやりやすいですね。 ＃ただしURLエンコードされない文字、[A-Za-z0-9_.*-]に限りたい ＃＃mozilla以外で"_.*-"がエンコードされないかどなたか確認していただけません？ > これだけだと、特殊ページも含めて最大1万ページしか扱えません。しかしな > がら、殆どのユーザにとっては十分な広さを持った空間と言えるのではないで > しょうか。 > ＃現時点で公開されているfswikiのサイトの99％はカバーできそう（推量） > > 1万件を超えたら、次の1万件を収容する空間を確保します。例えば、 > 「10000〜1999」を使うようにします。このあたりは検討の余地アリ。 > ＃Y10k problem（RFC 2550）が参考になるかも 個人的には1万ページを越えるようなものをFSwikiで管理するのがそもそも間違 いと思わなくもない（笑） > 数十、数百ページ程度の個人サイトならば > http://www.example.net/user/wiki/wiki.cgi?id=3643 > のような比較的「目に優しい」URLになります。 http://www.example.net/user/wiki/wiki.cgi?id=r1H 微妙かな。2文字だと3844ページ。微妙かな(^^; http://www.example.net/user/wiki/wiki.cgi?id=r1 > ただどれだけ短くとも、URLを口頭で伝えようとするときに？や＝があるのは > 邪魔に感じるかもしれません。そういう人には、トップページのURLと、「○ > ○（特定のキーワード）で検索してね」のほうが良かったりします。 > > また、根本的にいって、URLを手で打ったりなどと言うシーンはいまや殆どな > いですよねぇ？私の場合では、見る側としては検索する、Bookmarkから、アン > テナから、リンクを辿るような動きになりますし、サイトを作る側、あるいは > メールに書く場合も、リンクミスが怖いしURLなどはコピペが基本になってい > ます。リンクを元に記事を書くようなbookmarkletを用意すれば、十分かと思 > います。参照：BugTrack-plugin/88 > > googleがかなり一般化して、検索結果のURLを貼るなんてことが日常的になる > につれて、URLエンコードに対する違和感もどんどん減っているのではないで > しょうか。 英字も使う理由、数字のみにしない理由は、IDは積極的に使うべきものではない という前提のがあるのと、思った以上に短くできる、さらにmktempがそのまま使 えるというのです。もし数字のみがよい場合はmktempが生成したものをBase64と みなしてデコードした数値を用いる手もあり、対応可能ということを付け加えて おきます。 ただ、RDBMでそのあたり（自動生成ID）がどの程度の桁数なのか、自由度がある のかは知りません。 なお、ここまではあくまでURLで使われる可能性があるという前提での話です。 その場合はIDとページの実体との関係が永続化される必要があるため、性質的に ファイル名と同じなのでファイル名から単純な変換で求まる方が効率的なだけで す。 もし、cgiの外、つまりURLとしてもwiki内としても、ユーザのページ管理上とし ても使わないのなら、IDはブラックボックス化して、永続化レイヤ外ではファイ ルハンドルのように変数に入っている識別子としてのみで、触らないようにすれ ばよいと思います。この場合、ページ名などとファイル（ページの実体）との関 連は永続化する必要があるにせよ、プロセス内で使われるID自体はプロセス間で 違っていても問題ない（プロセス外に出ない＝永続化された情報がない）ため、 極論すれば永続化レイヤ内部で使うインスタンスや、ファイルハンドルそのもの もありかも知れません。 さらに、永続化レイヤの外にIDを出さずなければ、ページ名とファイルとの関連 を永続化さえすればファイル名は任意につ蹴れます。これであれば3.*でも新た な永続化レイヤを作れば対応可能ですね。 では。 -- typer typer_jp****@yahoo***** Noboru Katoh typer****@chive*****
Fork