青木日記

■ ruby-dev summary × 100

次の ruby-dev summary で 100 号です！

(16:27)

■ 『Rubyレシピブック』サポートページ

『Rubyレシピブック』のサポートページを公開しました。

• http://www.notwork.org/rubyrecipebook/

(16:37)

■ LL weekend

http://ll.jus.or.jp/

正直どーしよーかなーって思ったけど、 どうせ安いんだからと後悔しないように申し込んでおいた。

しかし参加費は学生 1500 円なのに郵送費が 600 円って、 比率としてどうなのよ。

(21:18)

■ 「Subversionが嫌い」……のつづき

http://d.hatena.ne.jp/wakatono/20040601#p7

Subversion、新しいデータベースを実装しているんですね。 ちょっと試したい気分になってきました。

(01:07)

■ cvs.loveruby.net 停止

Just another Ruby Porter,より
http://www.st.ryukoku.ac.jp/~kjm/security/memo/2004/06.html#20040609_CVS

CVS pserver は果てしなくやばそうなので、 対策が済むまで cvs.loveruby.net を停止します。

なお BitChannel (Wikiサイトのほう) はローカル CVS なので関係ありません。

(02:03)

■ 分散BitChannel

(ツッコミに書こうと思ったけど長すぎたので移動)

そうか……もしBitChannelを分散管理できるようにしたら情報テロが (以下略)

ていうか CVS じゃ分散ってありえないよな。 BitKeeper ならできるかもしれない。 レポジトリを分散して適当にマージ。 適当にマージはできないだろ (一人ツッコミ) マージできそうなとこだけマージ？ 全ドキュメントに世界共通の ID を付けて、同じ ID を 持つドキュメント間でだけマージするか。 知らないうちに別のホストでアップデートされていくドキュメント。 いいなあ。萌えるなあ。

世界共通の ID と言えば GUID か？ つーか MD5 checksum 程度でもよいかもしれない ……いやそれじゃやっぱりだめだよな変更されていくんだから。 いっそのことタイトルを使えばいいんだろうか。 かなりの唯一性が要求されるが、そのくらいは必要か？

あとはどういう経路でプッシュ (or プル) するかだ。 BitChannel が稼働しているホストを探索するにはどうするか。 うーむこのへん勉強不足だな。ネームサービスみたいなものを どこかに置いとくしか思いつかん。DNS だってルートサーバの IP アドレスは覚えさせとくわけだし、なんらかの形で 一段目が必要になりそうな気がする。

どの情報をプッシュするか。全部プッシュしても面白くないな。 均一になるのを目指してるわけじゃない。 ……既に手元にある情報を元に、似ている情報を集めるのはどうか。 あー、でもそれだと似たような情報ばかりを集める結果になりそうだな。 手元のプールからランダムでキーワードを選べばちょっとは分散されるだろうか。

ときにはすごく意外な情報も入ってきたほうがいいなあ。 Winny みたいに情報を仲介する過程でキャッシュすることにして、 そのキャッシュからもランダムでピックアップするか。

そういうのは人の日記を適当に巡回してれば十分じゃないかって気がしてきた。

Wikiで日記を書く人がいるけど、 日記が流通して勝手に続きが書き加えられたら面白いよな。 漂流する交換日記？ いや交換してないから漂流日記……だと漂流教室のようだ。

同じ ID を持つドキュメントであっても、 プログラム外から破壊する意図を持って変更されていた場合にはどうするか。 いやその前にどうやってチェックするか。 データは追記のみ valid な形式とし、 履歴部分の MD5 sum をつねに併記すればよいか。 未知のブランチがあった場合はどうするか。

マージに失敗した場合はどうするか。 ……その前に、どんなときに失敗するのか。 常に分岐しつつ追加されていくとすると、 マージは起こらないのではないだろうか。 ……ユーザが意図的に指定すれば発生するか。 main trunk へ収束させる圧力が必要かもしれないな。

そーか。履歴を束ねたときの MD5 sum があれば、それが ID になりうる。 いや違う、履歴を束ねた全体の同一性が保証できない。 やはり別にドキュメント ID は必要だ。

実装の問題はマージか。ネットワーク関係はさして問題ない。 下手すると BitKeeper 以上のレベルを要求されるか？

なんでこんなことを考えているのだろう……

そうか URL だ！ URL があった！ URL は唯一のキーとして使えるかもしれない！

と、一瞬喜んだけどタイトルとたいして差がなさげ。 原作者を明示する意味はあるやもしれない。 偽造も簡単なのでむしろ危ういかもしれない。

むー。普段ウェブで読むドキュメントの署名が (それなりに) 信用できるのはなぜだろう。 それは URL がなんらかの形で物理ホストと連結されているからではなかろうか。 URL がホストと切り離されるとその瞬間に URL は単なる情報と化し価値が無くなる。 例えるならば、評価して値の得られる変数には意味があるが、 評価できない (未定義の) 変数は意味がない。ということかな。

他人のシステムにあるドキュメントは (クラックしないかぎり) 改竄しようがない。 変更を加えたら必ず自分のホスト (のBitChannelノード) で公開することにすれば、全ての変更を検証できる。

……いや、分散ドキュメント側の URL が改竄されたらやっぱりだめだ。 やっぱそのために MD5 sum は付けとかなきゃ。

あー、違う違う。 これでは誰がその変更を行ったかということしか検証できないんだ。

そういえば arch は BitKeeper と似たシステムだったっけ？ 見てみよっと。

(03:53)