• MS、bCentralと.Net Frameworkに互換性がないことを明言 - http://japan.cnet.com/news/ebiz/story/0,2000047658,20052849,00.htm

bCentralとはまたすごく懐かしい名前だな。もはやそれが何を意味しているのか忘れちゃっちゃよ。で、ググって見たら、

• bCentralについて - http://business.msn.co.jp/about.asp

ってのを見つけたんだけど、さらにそのトップページ（http://business.msn.co.jp/）に行ってみたら、

平素は bCentral をご閲覧いただき、ありがとうございます。
当サイトは、7月31日をもちましてクローズすることとなりました。

となっていた。この7月31日ってのは2003年なのか？　それとももうクローズしているのか？　下位コンテンツは生きているみたいだけど、トップからのリンクがなくなっているってことはすでに閉鎖済みなようにも思えるな。で、さらにググって見ると、

• Microsoftの次世代Windows構想「Microsoft.NET」 - http://pc.watch.impress.co.jp/docs/article/20000630/msnet3.htm

>MSN.NETやOffice.NET、bCentral for .NETなどは、ネットワーク上のサービスとして提供される。

と書いてあるのを見つけた。このころはまだ統合するつもりだったんだね。というか、.NETとは何なのかがマイクロソフト社内でも分かっておらず、ひとまず当時マイクロソフトがやっていることすべてに.NETとつけてみただけだったんだろうね。この連載を最初から読むとなかなか感慨深いものがある。

結局最終的には、新しいJavaライクなプログラミング言語であるC#（とおまけのVB.NETとかC++.NETとか）および、それ用に新規に作った巨大なクラスライブラリが動作する、仮想マシン環境のことを.NET（Framework）と呼ぶってことになったんだろうな。.NETの正体はマイクロソフト版Javaのことだったわけだ。

公開用WikiLikeを作る上で考えている改善案。でも、日本の平均的（だと思われる）レンタルサーバーとかでまともに動くように、PHP+MySQLなコードを書き直すのってうざいなー。どの程度のライブラリまで使っていいものかの判断も付きにくいし。

• ユーザーのメール／URLを入力できるようにする（主にコメント用）
• ページ作者のみが更新できるモードを作る
  • ID、トリップによる認証（XSS対策をかなりがっちりやらないとなー。JavaScript有効だと弾くようにしたろうか）
• キーワードに特定の語が含まれているかどうかで、ページの権限的な意味づけをする
  • HiddenPageで通常のページとして一覧表示されなくなる。SID指定で直接行ったときだけ表示される。
  • PrivatePageでCookieのuser_name、user_tripがマッチした人だけが表示できる。
• ページのmodifiedとプロパティのmodifiedを分け、実際に更新された日時と表示用の更新日時を分離する。
• ページ名＝ユーザー名であるページを、そのユーザーのホームページとする。ホームページIDを使ってユーザーごとのさまざまな処理を切り分ける。
  • ex)http://some.domain.com/view.php?user=32でid:32がホームページのユーザーの最新記事n件を表示する
• WikiNameの自動リンクをオン/オフできる。
• マルチユーザーモードと単一ユーザーモードを切り替えできる
• PHP CGIモードとApacheモジュールモードを切り替えできる（やりたくねーなー）
• TrackBack/PingBack/Referer/コメントによる反応を統合管理する
• 新しいきれいなWiki系フォーマット体系＆レンダリングエンジンを作る
• 言葉交差点との自動連係（キーワード登録）
• ログイン/ログオフをつけて、Cookieの有効無効を手動で変更できるようにする
• creative commonsあるいはGNU FDL表示対応。
  • というかソフト自体のライセンスをどうしようかなー。サンプルコード扱いってのはダメかね？

• Pingback plugin - http://www.rubyist.net/~tamura/d/?date=20030315#p01

どうやらtDiaryはひとまずPingBackに対応するみたいだなー。PingBackは実用的にはTrackBackよりもRefererとの差が少ないんで、すでにRefererを表示しているtDiaryに載せてもあまり意味がないと思うんだけど、PingBackの方が仕様が明確で実装するのが楽しそうだというのが大きいんだろうな。

TrackBackを必要最低限実装するのは、一言掲示板を実装する程度の作業だから技術的には何も楽しいことはないし、必要最低限以外の部分までフルに実装しようとすると、今度はやたらと面倒くさい割にはその意義を感じられない（し、仕様もいまいち）。

tDiaryがPingBackに対応するんだったら、一応俺もPingBackに対応しておこうかな。でもフルにPingBackを実装する気にはなれないんで、受信側は一応実装しつつ、送信側はTrackBackのオプション的な実装にしよう。TrackBack Ping URLを記述する横にPingBackチェックボックスを用意して、PingBackチェックボックスが立っていたらそのURLをPingBackとして処理する方針で。

でもそれをtDiaryに送るのって、普通にリンクを張って10回とか20回とかクリックしてたくさんRefererを送るのと大した差はないように思えるな。表示側でちゃんとRefererとは違うとわかりやすく表示されると差別化できるかな。あと、PingBackオンで更新すると処理が重くなるから、誰も使わないなんて恐れもある。リンクごとにPluginでいちいちPingBackを送るかどうか指定するようだと、PingBackの意味がなくなりそうだしなー。まあその辺は実際に実装されて使われるようにならないと分からないか。

• オリックス本拠地、「ヤフーＢＢ球場」に名称変更 -http://www.yomiuri.co.jp/national/news/20030315i401.htm

>プロ野球オリックス・ブルーウェーブの本拠地「グリーンスタジアム神戸」（神戸市須磨区）の名称を決められる「命名権」を、ソフトバンクグループが購入することが１４日決まり、今年のシーズンから「ＹＡＨＯＯ！（ヤフー）ＢＢスタジアム」に名前が変わることになった。

命名権なんてばら売りしているもんなんだ。で、「YAHOO! BBスタジアム」ねー。なんか長持ちしなそうな名前だね。「Yahoo! BB」って名前の印象がもはや最悪だからなー（ってのは一般的な評価ではないのかな）。まだ「Yahoo!スタジアム」くらいにしておいた方が良さそうな気がする。

• ブレスレット型映像記憶端末──NEC、未来デバイスをCeBITに出展 - http://www.zdnet.co.jp/news/0303/14/njbt_05.html
• Resonantware - http://www.nec-design.co.jp/showcase/indexj.html

waccaとnaveは根本的なインターフェースの改善、P-ISMは身の回りのものにデジタルインターフェースを統合＆融合させるアプローチか。duo-pcとかduo-phoneは何がどうなっているのかよく分からないや。waccaとかP-ISMの実用レベルのものが普通の値段で発売されるのはいつ頃なんだろうなー。

• [tDiary-devel] Re: Trackback or Pingback Plugin - http://www.tdiary.net/archive/devel/msg00619.html

Pingback plugin from Rubyにまつわるえとせとら日記の続き。

P2PとしてのPingBackの実装に関しては、利用者の意識においてのRefererとの違いがなさすぎる点（同様のことははてなダイアリー的TrackBackのはてなダイアリー内での利用にも言えるんだけど）に、あまり大きな意味を持てないでいるんだけど、上記で触れられているゲートウェイサーバーを介してPingBackを実装するってのは確かに面白そうだなー。

ゲートウェイサーバーへの依存が大きくなってしまってP2Pの手軽さは薄れてしまうけれども、ゲートウェイサーバーに集約された情報によってtDiaryサイト間のリンク状況が一望できるようになるわけだ。tDiaryに限らず一般に開放すれば、そのゲートウェイサーバー利用者全体のリンク状況が一望できる。

ただ、ゲートウェイサーバーの安定運用が面倒だろうなー。サーバーが落ちてしまうとすべてのユーザーの更新が重くなってしまう（タイムアウト待ち）だろうし。

• Trackback情報を使って、サイト横断的に議論を閲覧できる未来 - http://www.otsune.com/diary/2003/03/15.html#2003031512S1

［tDiary-devel］ Re： Trackback or Pingback PluginみたいなPingBack集約サーバーを使っても同様のことはできるし、あるいはblogmapみたいに外部からリンク情報を集約するサーバーを使ってもある程度はできる。けれども、そうするとどうしても一カ所のサーバーに依存した仕組みになってしまいます。

TrackBackは、現時点では私が知っている中で唯一、集約サーバーを持たずにそういうことができる仕組みです。その肝はTrackBack＋RSS。

あるネタ元となる記事があったとします。で、その記事にはTrackBack Ping URLが埋め込まれています。TrackBack Ping URLに?__mode=rssをつけて呼ぶと、その記事にTrackBackしている別サイトの記事に関するRSS（サイト一覧情報）が取得できます（うちではまだ実装していないけど）。

TrackBack Ping URL?__mode=rssで取得したRSSの各アイテム（ネタ元に言及している記事URL）に対して、再びTrackBack Ping URLを取得しに行きます。すると、さらにその記事にTrackBackしている記事に関するRSSを取得することができます。以降、TrackBackがなくなるまで繰り返す。

という処理によって、ある元記事に関連した記事をツリー構造的に自動でたどることができるのが、TrackBackの描く未来像なわけです。もちろんいちいちすべてのTrackBack先をたどらなくても、RSSにはSummaryが提供されているので、Summaryで満足したらその枝の先をわざわざたどることもないでしょう。

このような仕組みは、非常に多くのサイトがTrackBackをフル実装していないとあまり意味がないので、現時点では有効活用している事例を見せることができないんですけど。上記のような処理を行うRSS Readerを作るのは結構簡単なんで、今度暇なときにでも（っていつだろう？）そういう動作するReaderでも作ってみます。

で、個人的に重要だと思うのは、TrackBack技術においては上記のような処理を行うために、情報を集約するサーバーが必要ではないこと。各サーバーが独自にリンク情報を持っていて、必要になったらそれをたどるだけなので、一カ所のサーバーに依存することがないわけです。

TrackBack Ping URLに?__mode=rssをつけて呼ぶと、その記事にTrackBackしている記事のRSSを出力する機能を追加。言うだけだとなんなんで、一応TrackBack関連の機能はフルに実装しておくか。じゃないと、Readerのサンプルを作る実験もままならないし。

channelノードに出力する内容を勘違いしていたんで、修正。ちゃんと該当の記事の情報を出力するようにした。あと、TrackBackが存在しないときにどう返すべきなのか、仕様書には書かれていなかったんで、MovableTypeサイトで実地で確認。itemなしのrssを返すのが正解なのね。要するに、__mode=rssでは、基本的にその記事単体のRSSを返しつつ、TrackBackが存在した場合は、そのTrackBack記事のRSSをitemとして出力するわけか。

• The Next Generation of TrackBack: A Proposal - http://www.mplode.com/tima/archives/000206.html

TrackBackの拡張案が出されていた。多分向こうでも現行の仕様（書）のできを叩かれているんだろうな。

>The specification document need more clarification and refinement particularly as to where the specification ends and specific implementations begin.

と書いてあるし、TrackBackをたどったら、

• TrackBack - http://engagebrain.com/index.php?p=33

>Seems I'm not the only person to think the current TrackBack mechanism sucks

という人もいたし。なんかtDiary界隈で叩かれたのと同じようなことがかつて向こうでも起こったのではなかろうか？って感じだ。

あと、

• TrackBack, Moving Forward - http://www.sixapart.com/log/2003/02/trackback_movin.shtml

>I think the fuzziest area is the auto-discovery option.TrackBack auto-discovery is currently tricky to implement and can be bandwidth-intensive.

ってあたりも、やっぱり向こうでも問題視されているみたいだね。あまりにも後付けっぽくて美しくない仕様だし、しかもXML表現を使う標準準拠な姿勢と、HTMLにコメントアウトしながら強引に埋め込む非標準準拠な姿勢がごっちゃになっているのも奇妙だ。

まあ俺の場合は、TrackBackの仕様自体と言うよりは、その基本的な考え方と、それが一般化することによって可能になること（Trackback情報を使って、サイト横断的に議論を閲覧できる未来 from void GraphicWizardsLair( void ); //）への期待感から支持しているんで、仕様（書）の不出来はあまり気にならなかったけど。

でも、「現行のTrackBackをそのままサポートしなくてもいい」とは何度も言っているけどね。どう考えても、同様のもっと優れた仕様を作ることは可能そうだし、MovableTypeやB2ユーザーがすでにある程度いるという既成事実を差し引いても、もっといい仕様を根本から作り直す価値はありそうだからな。

えーっと、話が逸れた。

で、次世代TrackBackの仕様案がいろいろ書かれているわけだ。ひとまずざっと挙げてみると、

• TrackBackのやりとりを完全にHTTP準拠にする。結果を201 Createdとか200 Successとかで返したり。
• content negotiaionのサポート。って具体的に何を差しているんだろうな？　charsetとかをこのあたりでサポートしてくれるんだろうか？
• XML（RSS）をPOSTすることができるようにする。ってのは、単に対象性（戻り値だけがXMLなのは気持ち悪い）のためかな？
• RSSと要素名をあわせる。ってのは確かに実装しているときにexcerptとdescriptionを使い分けるのが気持ち悪いからな。あと必須とかもあわせるらしい。
• auto-discovery周りの仕様を洗練させる。RDFの代わりにRSSを使う。ってのは具体的にどうするんだろう？　少なくともHTMLに強引にRDFを埋め込むのはやめたいんだろうな。PingBackみたいにひとまず統合インターフェースへのURLを受け取って、統合インターフェース経由で記事URLに関するRSSを受け取り、それに含まれるTrackBack Ping URLを得るって感じかなー。LINKタグを使って云々って書いてあるから、やっぱりそういうことかな？　素直にauto discovery周りの処理はPingBackを参考にするといえばいい気もする。

あと、細かいことがいくつか書いてある後に、結構興味深いネタが一個書いてあった。

>FOAF and digital signatures. Should the concept be worked into the specification?

これやって欲しいなー。FOAFに関しては前にどこかで書いたはず。と思ったけど、検索しても見つからないなー（http://ishinao.net/pukiwiki/?%5B%5BFriend-of-a-Friend%5D%5Dにあった）。XMLで人間および人間関係（交友関係）を表現しようという規格。RSSにFOAFを混ぜて、サイト同士の関係情報が表現できると、利用方法はあとからいろいろ思いつきそうだ。

まあこんな感じで、まだまだTrackBackの仕様は大幅に変わっていきそうだね。あんまり細かくついていく気力はないぞ。

Trackback情報を使って、サイト横断的に議論を閲覧できる未来 from void GraphicWizardsLair( void ); //で触れた、TrackBackをたどってWebサイト間にまたがった議論をツリー構造化するツール「TrackBack Tracer」。手元の環境で雰囲気だけ動くようになったので、画面だけ公開。

TrackBack Tracer α版

適当なルート記事のURLを入力してボタンを押すと、まずそこの記事内に含まれるTrackBack Ping URLを取得。そして、その記事にTrackBackしている記事を子ノードとして追加。あとは、子ノードに対して右クリックメニューから「TrackBackをたどる」コマンドを発行すると、さらにその記事にTrackBackしている記事を探していく。

試しに作ってみた感触では、処理にかかる時間はそれほどでもないんで、まあまあ使いやすいかなという印象。Web側の表示はIEそのまま使っちゃうので十分っぽい。ただし、正しくないRSS（charset宣言が間違っているとか）で解析エラーが出たり、HTML中にRDFが含まれなかったり、複数のRDFから妥当なRDFが検出できなかったり（URLの揺らぎ）とか、そのあたりのエラーハンドリングに一番手間がかかるかも。

まあ、実用レベルに達するのはまだまだ時間がかかることでしょう。ひとまず理屈通り動くことが確認できて満足したんで、これに手をかける優先順位は低くなったから。現時点ではTrackBackで議論をたどれるサンプルも少ないしね。

---

うーん、俺的には「TrackBackによってこういうことが出来るんだよ」とわかりやすく絵で見せるためのサンプルとして作ってみただけで、これに関しては現時点ではどうでもいいと思っていたんだけど、なんだかこれの反響が一番大きいみたいだなー。

やっぱりみんな、絵があってわかりやすいのが好きなのか。みんなもっと字に萌えようよ！　英語仕様書ヽ(´ー｀)ノまんせー。

しょうがないから、もうちょっと世の中にTrackBackとRSSが普及してから作る予定だったRSS Reader＋TrackBack Tracerを真面目に作ることにしようかな。でもそろそろ俺の自由時間が終わりを告げそうな予感。

---

現在の開発状況については、「RSS Reader＋TrackBack Tracer」でやってますよ。