いまだ体調は回復せず。薬の効いているときと効いていないときの落差が激しい。でも今日は買い物に行かないとなー。

この天然さん（http://masao2002.tdiary.net/20021201.html）はいったい何ものなんだろう？　フリーの編集者っぽい記述が見受けられるけど、この対人スキルのひどさで編集なんて出来るのか？　それにしてもさいたまー！病院（http://www.aiseikai.or.jp/）を彷彿とさせるホームページ（http://www.masao-k.net/）だ。

頭痛とだるさが全然取れないので今日は休み。この体調不良いつまで経っても治らないな。普通に安静に暖かくして熟睡して、大汗をかいてすっきり快癒したと思っても、ちょっと涼しいと感じるとすぐに元の木阿弥になる。なんか風邪とかではなく根本的な体調不良のような気がしてきた。といいつつ病院には行っていないんだけど。派手な症状がないとどうも病院に行く気がしないんだよなー。

TrackBackを実装するの続きを考えてみる。

情報を受け取るインターフェースと情報を受け渡すインターフェースは、その実装（管理）責任者が異なるため、分けて考えた方がいいだろう。同じシステム同士でのやりとりならば統一して考えることが出来るが、ひとまずはシステムに縛られない汎用的なインターフェースとして考えてみる。

情報を受け取るインターフェースというのは、

• 他のサイトやクライアントツールからのTrackBack通知を受信する

のが目的。

自システムの「どの記事（記事ID）」に対して、「どのような反応（外部サイトのURL、コメント本文、反応者情報（名前、メールアドレス、url））」を受けたかを受信し、記録する。具体的な処理に関しては、受信処理と記録処理の2段階に分けて考えた方がいいだろう。さまざまな拡張情報を受信しうるが、そのすべてを記録するとは限らないし、受け取った情報にシステムでさらに独自情報を付加して記録することもありうる。

情報を受け渡すインターフェースというのは、

• TrackBack通知を発信する
• TrackBackされる情報元として、情報ソース（引用文）を発信する

という2パターンがありそう。

後者はTrackBack関連のインターフェースというよりは、RSSとか2chのdat直読みみたいな、コンテンツのrawデータ（通常のWebブラウザ向けではないコンピュータ同士の通信用フォーマット）を受け渡す仕組みみたいなものなんで、そっち方面の機能として考えた方がいいのかもしれない。具体的な機能としては、あるURL（外部サイトの特定の記事を差す）を指定すると、自動的（ネットワーク経由で）にその本文を取り込んで、その記事を引用したコメントを記述するフォームが表示される、といったイメージ。もちろんその他TrackBack通知に必要な情報も自動的に取り込む。

そして前者がTrackBackの基本となる通知側の仕組み。いまいち把握し切れていないけれども、Movable Typeでは他のサイトへのTrackBack通知を送る仕組みは、あんまり洗練されたものが用意されていない気配。それはちょっといまいち。出来ればある記事urlを指定して「この記事にTrackBack通知する」みたいなコマンドを発行すると、付加情報を入力するフォームが表示されて、それをPOSTすると自動的にTrackBack通知が行われるみたいな感じになっているといいな。

もちろん上記みたいな流れはTrackBack通知専用のフォームという訳ではなく、自サイトのシステムで他のサイトの記事への反応記事を書くときに、反応元URLとしてTrackBack対応サイトのurlを書いておくと、そのurl文字列から自動的にTrackBackインターフェースの有無の問い合わせを行い、もしもTrackBackインターフェースが用意されていたら、自サイトの記事としての投稿処理を行う裏タスクで、反応元サイトへのTrackBack通知も行われる感じ。

現在のWikiLikeでは反応元を明示したblockquoteは使えないけれど、hnf互換コマンドを実装した場合は、たとえば、

CITE http://somedomain.com/somepath/?id=123 引用元名称
引用文引用文引用文引用文引用文引用文引用文
/CITE
コメント本文コメント本文コメント本文コメント本文コメント本文コメント本文

みたいな記事をPOSTしたら、somedomain.com/somepath/に対してTrackBackインターフェースの存在確認を行い、もしも存在したらそのTrackBack受信インターフェースに対して、http://somedomain.com/somepath/trackback.cgi?id=123;author=someont;url=someurl;comment=somecomment;みたいな通知が自動的に行われる（という仕様には具体的にはいろいろ穴があるので要検討）。

データに関しては、最初は気軽にGET、POSTして引数渡しするのが手軽かなーと思っていたんだけど、本当に汎用インターフェースとして考えた場合に、日本語文字コードの問題とかが結構ややこしいことになりそうだ。Googleみたいにie=***;oe=***で文字コードを指定する手軽な実装方法もあるだろうけど、ここは逆にxmlで文字コード宣言をちゃんと行って、受信側が文字コードを適切に解釈すべしとしておいた方が、逆にあとあと面倒が少ないのかも。

Web日記サービスみたいなもので、集中サーバーでデータの管理をしつつ、そのコンテンツの配信は各ユーザーがそれぞれアカウントをもつ個人サーバー領域で行う、って形式には需要があるのかなー。

たとえばtDiary.netみたいなところでは、コンテンツの管理から配信まで全部サービスしてくれるけれども、コンテンツの管理自体はtDiary.netでやりつつも、その最新日記ページおよび過去ログページについては、ftp経由で各ユーザーの個人サーバー領域に（差分）アップロードして、一般閲覧者はそっちを見るという形にしてしまうパターン。

メリット、デメリットを並べてみると、

• メリット
  • サービスを提供するサーバーの負荷が大幅に低減できる
  • サービスが終了してもユーザーには自分の管理サーバーに過去ログhtmlデータが残る
  • 自分のページのurlを自分で選べる（日記ページだけ別サーバーとかならなくて済む）
• デメリット
  • ユーザーのftpアカウントの管理を行うというセキュリティ的なリスクを管理者が負わなければならない
  • 自動ftp関連の設定がちょっと（一般ユーザーには）難しいかも

ちょっと考えてみる価値があるサービス形態なのかも。特にASP（アプリケーションサービスプロバイダーの方ね）とかで商売をやる際に、こういうやり方でいけるものも結構ありそうだな。

飲みたくなくても無理矢理水分をたくさん取って小便として排出していたら、なんだかずいぶん調子が良くなってきたかも。汗をかくだけじゃ足りないのかな。

• Arrows refused entry! Into the 2003 season - http://f1.racing-live.com/en/headlines/news/detail/021202113540.shtml

あらアロウズは申込みはしたけど、FIA側から断られてしまったのね。というのはまあどうでもよくって、ジョーダンのセカンドドライバーはまだTBA（to be announced：後日発表）なのね。佐藤琢磨はちょっとキビシイかもなー。スポンサー集めに走り回るようなタイプにはあんまり見えないし、いまどきの日本企業はF1スポンサー候補としてはいまいちだし。

いまだ体調は回復せず。でもこれ以上寝ていてもしょうがない気がしてきたんで、午後から出社。ケツが決まっている（すでに一回延長している）仕事なんで、それだけでも終わらせておかないと。で、埼京線に乗ったら快速は臨海線車両に変わっていた。長座席を3人：4人に分けるバーがついたんで、長座席の利用効率が多少向上するかな？　で、渋谷まで電車に揺られてきたらとても具合が悪くなった。頭痛が痛い。今日はちょっとだけ作業をしたら帰ろう。

健康食品と風邪薬と健康ドリンクとを体内に注入したら、一気に体感体温が上がったよ。漫画的に言うと私の背後にオーラが燃え上がっている感じ。でも頭痛が引かないのは何故？

• “便所の落書き”から抜け出すには 〜有意義な議論を行なうための掲示板ツール - http://www.watch.impress.co.jp/internet/www/article/2002/1203/hbc.htm

基本的には既存技術の組み合わせって感じだな。良くできた（？）スラドというか。ただ、 >投稿を公開する“タイミング”を制御する って部分にオリジナリティがある。確かに時系列で表示されるシステムの場合、投稿する（表示される）タイミングってのはかなり重要な要素になるんで、それを制御しようという着眼点はいい。

ただ、このシステムは基本的に、あまり参加者が多くなく、かつ参加者の粒がそれなりにそろっていることを前提に作られたシステムのようにみえる。学校とか企業とかで使われる分にはそれで十分かもしれないけど、雑多な参加者が使ってもうまくいくような方向に発展するといいな。