_ 納税証明書がない

車検の季節がやってきて、また納税証明書が見あたらない。ということで、久しぶりに永福の杉並区出張所に行ってきた。ああだりい。

_ 1470.netリニューアル計画

長々やってきたストレスの溜まる仕事が一区切りついたんで、1470.netの全面リニューアル計画に着手することにした。ひとまず周辺ライブラリを地味にそろえて実験しながら、方向性を固めていこう。

_ どっちがましだろう

Trackback vs Pingbackを読んだだけで、元文章はどっちも読んでいないんだけど、ひとまずtrackbackとpingbackを比べてみると、

• trackback
  • いいところ
    • 実装・利用例が多く、すでにデファクトスタンダード化している
    • （URLのみやりとりするping backと比べると）得られる情報量が多い
  • 悪いところ
    • 仕様レベルでノーセキュリティ。SPAM対策が難しい。
    • trackback ping URLの仕様うざ。機械専用の情報を人間様に入力させようとは、何事か。
    • auto discoveryの仕様もうざ。ないよりはましだし、動くことは動くけど。
    • trackback ping URLのせいで、リンク先URL、通知先（ping）URLを二重管理しなければならない。しかもその二つを結ぶラインは、auto discoveryという非常に弱いラインしかない。
    • 文字コード問題には現行仕様では対応している（結局初期の頃にshiroさんが言っていた仕様になったってことか）けど、実装レベルで対応しているところはほとんどなさそう。仕様のアップデートに関するアナウンスよわっ。
• pingback
  • いいところ
    • シンプル＆スマート。逆に言うと、必要最低限。
    • 人間は単にリンクするだけでOK（どこにどうやって送信するかなんて意識しなくていい）。
    • URLと受信するサーバーとが切り離されている（HEADなどに受信サーバーURL（固定）を入れておくだけでいい。trackbackもある程度は切り離せるけど、エントリー単位の情報は共有する必要がある）
  • 悪いところ
    • ほとんど使われていない。
    • これも特にセキュリティはないな。利用例が少ないからターゲットになっていないだけだろう。
    • 情報量が少ない（URL情報しか持っていない）。

ちなみにpingbackは2、3年前に調べて以来全然見ていないから、現行仕様では何か変わっているのかもしれない（けど、きっと変わってないと思う）。

とか書いていて思ったけど、trackbackはWindowsライクな仕様（リッチだけど穴を塞ぐのが難しい設計）で、pingbackはUNIXライク（シンプルなツールを、外部と（パイプで）つないで使いこなしてね）な仕様、なんてイメージが重なるな。

現行trackbackの利点って、すでにデファクトスタンダード化しているところだけって気もするし、いろいろ問題点を解消しようとした結果、現行仕様と互換性がなくなったりするようならば、何もtrackbackにこだわる必要はないよなー、とは思う。

っつーか今更URLをキーにつながるなんてチープなことは考えずに、みんなHyper Estraierの全文検索機能を持って、P2P連携を使って全文検索でつながっちゃったほうが話が早いじゃん、ってのはどうだろう。まあP2P連携もそんなに大量のノードはつなげられないだろうから（ってHyper EstraierのP2P連携機能は使ったことないけど）、動的ノード解決の仕組みを考える必要があるかな。

ってなんだかずいぶん話が発散したな。

_ script.aculo.usにすることにした

そろそろAJAX関連も実用レベルで使い始めなきゃなーって感じなんだけど、たくさんあるライブラリ群を調べる気力がない（し、高度なJavaScriptライブラリたちを正しく評価する能力もない）んで、雰囲気でscript.aculo.usを基本ライブラリとして使うことに決めた。これってスクリプタキュラスって読むの？

フレームワーク的な部分とユーティリティ的な部分を（script.aculo.usの一部として使われる）prototype.jsに任せ、基本的なエフェクト処理をscript.aculo.usに任せる、ってイメージでいいのかな？　あとYahoo!のUIライブラリあたりを部品として使いたいんところだけど、JavaScriptレベルでバッティングとかしちゃわないかな？

_ サーバーとクライアントでテンプレートを共有したい場合

データとテンプレートの配置 その3で書いたように、同じURL引数違いで出力フォーマットを変えるインターフェースを、作ったり使ったりして試してみている。基本的な方向性は悪くなさそう。

• データ層 - ここは好きにやる
• 汎用データ取得層 - ここは汎用クラスとして一般的なインターフェースを持たせる
• アプリケーション用データ取得処理 - アプリケーション内で共用するインターフェースとして作る（キャッシュとかはここでかます）
• データ出力層 - HTML、XML、JSON、TXTなどリクエストに応じて、形式を変えて出力する

なんて感じで作ってみている。

で、そういう作り方をしていると、データ出力層では出力形式に合わせて複数のテンプレートを使い分けたりするわけだけど、どうせならばHTML形式の場合に、リクエスト側でHTML展開する時に使うテンプレートファイルを指定できるようにしておけば、それでいいんじゃないかって気がしてきた。

JavaScriptでがりがり出力したい場合は、

http://example.com/path/to/resource?format=json

とかやって、JSON形式で受け取ったデータをJavaScript側でDOM操作なりJavaScriptテンプレートエンジンなりを使って出力してやればよく、たいていの場合はその方法を使うことになるんだろう。その場合の流れは、

1. クライアント - サーバーにリクエストを投げる
2. サーバー - データをJavaScriptが扱いやすいフォーマットで返す
3. クライアント - 受け取ったデータをJavaScriptネイティブな変数に展開する
4. クライアント - DOM操作やJavaScriptテンプレートを使って、データを出力する

どうしてもサーバーサイドにあるテンプレートを使いたい場合は、

http://example.com/path/to/resource?format=html&template=templatename

とかやって、必要に応じてサーバーサイドで部品レベルのテンプレート展開処理をしてもらい、その結果を受け取ればいい。その場合の処理は、

1. クライアント - サーバーにリクエストを投げる
2. サーバー - データを指定されたテンプレートで展開したHTMLとして返す
3. クライアント - 受け取ったHTMLをそのまま表示する

ただしこういうやり方は、サーバーサイド実装者とクライアント実装者が同じ場合にはやりやすいけど、そうじゃない場合（たとえば別管理者が公開しているリソースを利用したい場合）はそう簡単にはいかない。

けど、その場合はクライアント実装者が、自前のサーバーに簡単なプロキシ（＋テンプレート展開エンジン）を用意すればいいだろう。その場合の流れは、

1. クライアント - プロキシにリクエストを投げる
2. プロキシ - リソース提供サーバーにリクエストを投げる
3. リソース提供サーバー - プロキシにリソースデータを返す
4. プロキシ - 受け取ったリソースデータとローカルのテンプレートを使ってHTML展開処理を行う
5. プロキシ - 展開したHTMLをクライアントに返す
6. クライアント - 受け取ったHTMLをそのまま表示する

なんて感じか。

ひとまずそういう方向でいろいろ実験してみる。