ISHIDA Naoto
not20****@anet*****
2005年 4月 2日 (土) 15:03:24 JST
いしだなおとです。 以下では手を抜いて複数のメッセージに返信してます。 それと何度か下書きして書いたのですが前後のつながりが分かりにくいかも知れ ません。ご容赦を。 >「IDとページ名がかぶらないようにする必要がある」というのは永続化レイヤ >の話ですが、これは、 >・IDは内部管理 & 恒久的URL用 永続化レイヤというのはファイルシステム上のファイル名ですよね。これとペー ジ名は独立させたほうが良いのは、共通の認識になってきているようですね。 たけぞうさんも仰ってましたが、この永続化レイヤにおけるID（仮にページIDと でも呼びましょうか）を表面に出す必要は必ずしもないでしょう。 Wikiの外の世界からあるページにリンクするURLを示すもの（Permalinkです。恒 久的URL用と同義）は別にあってもいいと私は考えています。 また、履歴管理までカバーするIDを考えるとすると、あるページの遷移ごとに IDを振るという可能性もあるかもしれません。 こういった一般的に「ディレクトリ」といわれる仕組みは数多存在するわけです から、再発明する必要はないです。何らかのメタファを想定しつつ、それをどう FSWikiに持ち込む（適合させる）という視点で議論すると、問題点を整理しやす いのではないでしょうか。 UNIXのファイルシステム＝UFSを想定すると、多くの人にとって馴染みがあって よいように思います。 UFSでは内部的に「iノード」というものでファイルを管理しています。ページID はこれに対応するものとすると、内部のIDをユーザに意識させると言うのがUI的 によろしくないというのが私の主張の論点です。 ユーザにとってはページの内容（コンテンツ）が主眼であり、それを指し示すも のとしてページ名があるわけです。そのうえIDまで意識しなければならないとな ると使い勝手は低いかと思われます。 「IDも使える」というのは「IDが使われることがある」ということですから、 結局はユーザがIDを意識せざるを得なくなります。始めから、「IDはユーザが意 識しなくても良いもの」という前提をもって作るといいのではないでしょうか。 iノードやページIDの概念が有効であると言うのとは別次元の話です。否定して いるわけではないので、その点は申し添えておきます。 > よく考えたら、これまでのURLでもIDでもアクセスできるようにするのは > いいのですが、日本語ページ名だと > > wiki.cgi?page=URLエンコードされたページ名 > wiki.cgi?page=ID > > でしかアクセスできないということになりますよね。で、IDは今のところ > シーケンシャルなIDを振ることを考えています。自分で言っておいてなん > ですが、これはちょっと今いちかなぁという気がします。 ここで仰られている「ちょっと今いち」と感じる部分を具体的にすることができ ると、逆にどうすればよいかが見えてくるかもしれません。 単にシーケンシャルなIDを全否定されると、論を進めづらくなってしまう気がし ます。 一般に人はランダムな文字列を認識するのは苦手ですが、たとえば「4桁の数 字」程度なら、覚えやすいものとしてさまざまなものに使われていると思います。 > ・IDは廃止。ページ名とタイトルを別に設定できるようにする。 > →これまで通りページ名が一意な識別子になります > →1ページ=1ページ名(エイリアスはありかも) > →IDは廃止といってもデータファイルの保存にはIDを使用する これは上で述べた、ページIDは内部的なものとしてユーザに意識させない、とい う考えと一致するもののようですね。この部分はいいと思います。 > ・IDに加えて、ページ名とタイトルを別に設定できるようにする > →IDでのリンクも可能(Wiki的には不要かも…) > →1ページ=複数ページ名も可能(ただしページ名の衝突は不可) > 要は、ページ名と別にタイトルを設定できるようにしようということです。 > ページ名は英数字、タイトルは日本語、というような使い方を想定してます。 議論はこちらの方面前提に話が進んでいるようですが、これを否定的に捕らえる とすると、 ・非URI文字のページ名は不可とする ・各ページに、日本語もつかえる「1行description」を強制的につけさせる →ユーザの負担、特に新規ページ作成の障壁が非常に高い と言っているのと実際上変わらなくなってしまうのではないですか？ ＃YukiWiki系だと、Wikiテキストの最初の1行が自動的に1行descriptionになります > で、2つの案の違いはIDが表面に出てくるかどうかというところです。 この部分は前記の疑問（いまいち）とつながっているんですよね。 その疑問に対する私の考えを書いてみます。 ・ランダムな英数字や記号が13文字 ・単純なインクリメンタルの数字 のようなものは、使いたくないと考えます。1つ目のほうは、人によっては6文字 でさえもNGかもしれませんね。 単純なインクリメンタルの数字が悪いのは、UI以前の問題で、spamのような絨毯 攻撃に晒されやすいであるとか、新規ページ作成での衝突が起こりやすいという 技術的な問題です。 ここで提案したいのが、次のような方法です。 前提 内部だけで使われるID（ページID）に関してはもっと別に冗長な方法をとっても いいと思っています。 以下の案はPermalinkで用いるための識別子です。 ・0000〜9999までの1万個要素をもつ数列を、ひとつのまとまりとする ・この数列をランダムな順で並べ、それをIDとして使う ・ランダムな4桁数字を生成→コリジョン検出→衝突したら再生成、などをAPI化 これだけだと、特殊ページも含めて最大1万ページしか扱えません。しかしなが ら、殆どのユーザにとっては十分な広さを持った空間と言えるのではないでしょ うか。 ＃現時点で公開されているfswikiのサイトの99％はカバーできそう（推量） 1万件を超えたら、次の1万件を収容する空間を確保します。例えば、 「10000〜1999」を使うようにします。このあたりは検討の余地アリ。 ＃Y10k problem（RFC 2550）が参考になるかも 数十、数百ページ程度の個人サイトならば http://www.example.net/user/wiki/wiki.cgi?id=3643 のような比較的「目に優しい」URLになります。 ただどれだけ短くとも、URLを口頭で伝えようとするときに？や＝があるのは邪 魔に感じるかもしれません。そういう人には、トップページのURLと、「○○（特 定のキーワード）で検索してね」のほうが良かったりします。 また、根本的にいって、URLを手で打ったりなどと言うシーンはいまや殆どない ですよねぇ？私の場合では、見る側としては検索する、Bookmarkから、アンテナ から、リンクを辿るような動きになりますし、サイトを作る側、あるいはメール に書く場合も、リンクミスが怖いしURLなどはコピペが基本になっています。 リンクを元に記事を書くようなbookmarkletを用意すれば、十分かと思います。 参照：BugTrack-plugin/88 googleがかなり一般化して、検索結果のURLを貼るなんてことが日常的になるに つれて、URLエンコードに対する違和感もどんどん減っているのではないでしょ うか。 -- いしだなおと [ISHIDA Naoto] not20****@anet***** http://isnot.jp/
Fork