• calendar3
• dropdown_calendar
• todo

のプラグインを追加。

calendar3 は当月の日付を横一列に表示し、該当する日付の hover で内容を表示する。dropdown_calendar はそのままずばり従来年で横一列に表示していた月単位のリンクをドロップダウンリストで実現するもの。これは日記を何年も書き続けていくうちに使えなくなるな。

最後の todo は日記の編集画面ではなく tDiary の設定画面から ToDo を追加し、それを日記のどこかに表示するプラグイン。

File メニューに URL を開く動作がない。確かに普段はアドレスバー出てるけどさ。カスタマイズしてアドレスバー表示しないようにしたら URL を入力する方法ないじゃん。

へぇへぇへぇ

流行ってるかぁ？ 一部の夢想が連鎖してるだけのような気がするんだけど。問題がいくつかありますな。

P2P のメリット

• 帯域確保
• 負荷分散

と定義する。

基本的な疑問

• ブラウザと同等の機能を持ちつつ P2P に対応するクライアントを開発するのはかなり骨なような気がするし、ブラウザの完成度が高くなっている今日、新たなブラウザを作るのはちょっとどうかと。
• 何をもって Web と呼ぶのか？ P2P なら Web の基盤の上に乗る必要はないわけだし。
• ひょっとして普通のブラウザからも普通に見れる Web なんだけど、バックエンドが分散していて、それを大規模システムの管理スキルがなくても P2P アプリが勝手にやってくれるものが P2PWeb なのか？
• てゆーか P2P になったら認証とか Web のレベルで掛けるのはまず不可能になっちゃうので、かえってアプリケーションの作りこみが面倒になると思うんだが。

プロトコル

• ネットワーク部分の実装が plugable なブラウザならかなり面白いと思う（ぜひ幅広いプラットフォームに対応している Mozilla などで実現してほしい）

UI

• XUL とか X2Web が効いてくるのかな？ X2Web は IE 依存だからネットワーク部分の実装に自由がなくてダメか。

アプリ

• Web のアクセスの大半は view アクセスなので、コンテンツの配信と同時に view 部分を転送できるといいのかな？（これを「パッケージ」と呼ぶのがいいかも。）
• アプリケーションの作りこみが view アクセスの部分と更新部分で完全に切り離されてると実装が楽ですな
• 更新のアクセスは BitTorrent で言う trucker のようなサイトへ行い、その結果のコンテンツと view を担うアプリを流す。
  • 必要なら更新時に必要な計算処理も分散できるとなおよい。
• view を担うアプリは trucker サイトのアプリからのコンテンツ改変であることを検知してその伝播を受け入れる。（抜け道とかちゃんと考えてないけど一応セキュリティへの配慮は要るでしょ）

コンテンツ

• コンテンツの同期がいちばん楽です。たぶん。

なんかちょっと分かってきた。ような？

面白いけど、ちょっとイメージが漠然としてるな。

あ、例えば Wiki の「参加者」を限定するフレームワークとしてこの P2PWeb を使うと、CPU 負荷とネットワーク帯域を分散させた上で認証部分を Web から切り離せるので実装が楽ちんになるな。

こういうことがやりたいのか？ 匿名性が高いことが Wiki のメリットとはあまり思えないしなぁ。

ざっと眺めるとやはり勘違いしている人が渦の中心付近に居るようだ。早い話が P2P と blog という流行り言葉に食いついているだけの人。

メールに書かれた URL からクレジット専門のサイトへ。

クリックとちゃんと連動しないポップアップウィンドウを使うのはやめてくれ。