[観] Blogクライアントバックナンバー

観測気球 » Blogクライアント

Blogクライアント -- Hot Topics

【イベント参加レポート】第9回XML開発者の日

ちょっと出遅れてしまいましたが、「第9回XML開発者の日」の参加レポートをお届けします。

入場受付時に、HepCat というか、BlogWrite の人と遭遇。この人が、あの BlogWrite の人なのかぁと、ちょっと自分の世界にひたってしまいました (^^;

…… というのは、おいておいて。当日、行なわれた講演は以下の通りです。

第九回XML開発者の日
2006年11月24日東京・新富町日本印刷会館

開会挨拶

司会・進行役の村田真氏によるあいさつ。前回「第八回XML開発者の日」のテーマ REST を受けて、今回は microformats 周辺の話題が中心になるようです。ちなみに、「XML開発者の日」、私は今回がはじめての参加です。

現実的なRESTの実践

山本陽平氏による REST の話。前回の話からさらに突っ込んだ話ということで、あらかじめ前回の議事録を読んでみました。日常的に REST は使っているので、非常に興味をもって臨みました。

SOA に対して ROA (Resource Oriented Architecture) という造語を作ってみたり、REST の今後の方向性を知るにはいいセッションでした。

このセッションを思いっきり要約すると、以下のような感じ。

REST なサービスがどんどん増えている
ますます、データ重要
クールURI 重要
「データを Web に解き放て」

Ruby on Rails にみる RESTful アプリケーションの方向性

東芝ソリューション株式会社の川村徹氏による Ruby on Rails の話。次期バージョンの Rails で RESTful なアプリケーションが作りやすくなり、URI もほぼ自動的にクールURIになりますよ、とのこと。

Rails によるウィザード風アプリケーションの実装例は、これから Rails を使おうと思っている人の参考になるんじゃないでしょうか。このセッションの場合、手元に印刷物があるとより理解しやすかったと思います。このセッションで使われたプレゼンテーション資料は、「ぶろぐ。@4bit.net: 第九回XML開発者の日」で公開されています。

カレンダーアプリへの GData 実装

xfy Community の Masa氏と Tak氏によるセッション。プレゼン資料は、「xfy Community - 第九回 XML開発者の日「カレンダーアプリへのGData実装」スライド」を参照。

このセッションを聞くまで、xfy のことはほとんど知らないに等しい状態だったんですが、面白いことをやってるんだなぁ、と思いました。XSLT を独自に拡張した XVCD というのに非常に興味をそそられました。時間があったら、XVCD アプリケーションを何か1つくらい作ってみたいかも。といいつつ、作らないまま終わってしまいそうな感じもします (^^;

GData に関しては、私も「ここうさぎ」の Blogger 対応で使ってみようとしたんですが、結局、今の「ここうさぎ 3.x」では Blogger beta の方は使わず、「ここうさぎ 2.x」と同様、従来の Atom PP の方を使っています。GData は認証回りが結構やっかいで、特に Blogger の場合は、通常はユーザ名とパスワードによる認証でいいんですが、Blogger beta (GData API 越しの Atom PP)の場合は、ユーザ名と紐付いたメールアドレスが必要だったり、アクセス頻度が高すぎると(bot対策の一環だと思うんですが)弾かれたり、何回かに1回かは CAPTCHA 画像への URI が提示されて、その画像を人間の目で解釈した結果(機械的に画像認識させてもいいとは思いますが、一個人の力だけでは一朝一夕には対応しがたいです)を送らないといけないとか、いろいろ大変なんですよね。そんなこんなで、いずれは GData API をばりばり使いたいと思いながら、時間だけが過ぎていく日常を送っています。

Plagger: the duct tape of the Web

Plagger の作者、miyagawa さんがリモートPC経由でサンフランシスコからセッションを行なうという試み。映像もクリアで、音声もほとんど問題なし。後半は音声が若干途切れ途切れになってましたが、この程度なら、十分実用に耐えますね(参考: 「The short movies of Tatsuhiko Miyagawa at XML Developers' Day 9 - ohshima's blog」)。

このセッションで miyagawaさんが言っていることは、すでに自身が Web 上とかでも書いてることでもあり、知っている人はすでに知っている内容だと思うんですが、それでも、実際に自分の耳で聞くのは、それなりに説得力があって、いい体験でした。プレゼン資料は、「SF 到着・第９回 XML 開発者の日に出ました: blog.bulknews.net」から辿れます。

要約すると

Plagger はプラガブルな RSS/Atom フィードアグリゲータで、Perl で記述されています。すべての機能は小さなプラグインとして実装されていて、ユーザはそれを組み合わせることによって自分好みのフィードアグリゲータをつくることができます。Ray Ozzie は RSS はインターネットのUNIX パイプになれるといいましたが、Plagger はそれを乗りこなす UNIX シェルのようなものともいえます。
WikiStartJa - Plagger - Trac

ということになります。どっちかというと miyagawaさんの本音っぽい話が聞けて、そっちの方が面白かったです。あんまり Plagger のユーザ数が増えて欲しくないとか、そのためには Plagger を使うための敷居の高さは今くらいがちょうどいいんじゃないかとか、そんな感じ。

ODF と OOXML の標準化戦争

司会の村田氏によるセッション。「OpenOffice.org がベースの文書フォーマット ODF」と「the 2007 Office System (通称 Office 2007) の Open XML (OOXML)」の標準化にまつわる話。

ODF はまず OASIS で標準化されて ISO に提出。一方、OOXML は ECMA で標準化作業を行なった後、ISO に持ち込まれるものと予想。通常は国(またはそれに準じる組織)しか持っていない fast-track Procedure を使うことができる ECMA による標準化ビジネスモデルの話は、非常におもしろかったです。ECMA 経由だと、ISO の規格になるまでの時間を大幅に短縮できるんですね。

microformats に触れてみよう

シックスアパートの上ノ郷谷太一氏による、microformats 啓蒙セッション。自分の名前をネタに話を展開できるのは、ある意味おいしいです。うらやましいなぁ (^^;

プレゼン資料は、「XML 開発者の日に参加しました - 2xup.org」を参照。

Syndy Chronicle

ジャストシステムの山口琢氏によるセッション。この日2つ目の xfy 関連セッション(で、またしてもカレンダー絡みのアプリケーションの話)ということで、ジャストシステムの xfy への熱い取り組みが伝わってくる感じがしました。もしかして、カレンダーで一発当てようとしているのでしょうか?

Syndy Chronicle というのは、Web 上に点在する hCalendar 情報を拾ってきて「年表」を作るアプリケーション。「年表」といえば、dandelife のようなWebサービスを思い浮かべますが、Syndy Chronicle はローカルPC上で動きます。1970年以降の日時しか扱えないのが残念ですが、もっと過去のデータも扱えるようになると、歴史上のできごとの関連をしらべやすくなっていい感じになると思います。期待してます。

ブログエディタへの Microformats の実装

フィードパスの後藤康成氏と室田直匡氏によるセッション。プレゼンテーション資料へは、「Blogot: XML開発者の日終了」から辿れます。

feedpath のブログエディタ機能というか、いろんなブログに投稿するためのあれやこれやは、拙作の「ここうさぎ」ともろにかぶるだけに、興味深く聴かせていただきました。今回は、あくまでも microformats が話題の中心ということで、特に質問はしないようにしてたんですが、他の人が聞きたいことを聞き出してくれて、結局知りたいことを知ることができました。

「ここうさぎ」とかぶっているのは、API (XML-RPC API や Atom PP)に対応している blog はとりあえずいいとして(本当は、アメーバブログのような例外的な対応が必要な blog もあるんですが、それはおいておいて)、API の存在しない blog は、blog の管理画面とやりとりする処理を書かないと対応できないというところ。で、いちいち blog ごとに独自の処理を書くのはメンテが大変だし、管理画面の仕様変更のたびに書き直さないといけないし、いろいろ大変なわけです。この辺のコスト(開発コスト、管理コスト)を減らすため、どんな工夫をしているのか、非常に興味があったんですが、少なくとも現時点では、各 blog ごとに(管理画面やら実際に飛び交う http 電文の内容を解析して)独自処理を力づくで書いているとのことでした。Memory Recorder のように、各 blog ごとに管理画面の特徴を記述するためのテンプレートを用意して、あとはそのテンプレートにしたがって動く汎用のインタープリタを作って対応しちゃおう、とかそういう工夫はしてないようです。実は、このテンプレート記述を、各 blog クライアント(blog エディタ)でお互いに共通化、統一化して仕様を確立しちゃえば、みんなで幸せになれるんではないかと思うんですが、どうでしょう? たぶん、あのとき質問した人も、そういうことを考えているんですよね?

livedoorの金子さん

規格化されていないところを決めて行こうみたいなことは考えていますか？

Clash Cymbal Concerto - 第9回XML開発者の日に行ってきた

質問したの、金子さんだったんだ。

というか、いまは Plagger があるから、その辺の面倒なことは Plagger とそのプラグイン(と YAMLファイル)に任せてしまって、blog クライアントからは、plagger を呼び出すだけ、ってことにすれば、かなり工数を削減できそうです。ただし、クライアントPC上で動く「ここうさぎ」のようなツールの場合は、Plagger そのものと Plagger を動かすための環境一式を何らかの方法で配布する必要があるので、話は簡単ではないんですけどね。そういう意味では、feedpath のようなサーバ設置型ツールの場合は、エンドユーザに Plagger を配布する必要はないので有利ですよね。

「ここうさぎ」だけじゃなくて bookey のことも考えると、Plagger っぽい仕組みを自前で用意しようかな、とか考えているんですが、もしやるとしても実現はかなり先でしょう。単に作るだけじゃなくて、「エンドユーザに優しいインストール(もしくはデプロイ)」を実現しないといけないので、腰が重くなってしまってます。誰か、協力者が出てきて欲しいところ (^^;

まとめ

次回のテーマは「認証」?

懇親会

山本陽平さん、川村徹さんのいたテーブルの、「blog.8-p.info : XML Developers Day #9」のカトウさんの横に座っていたのが私です。宴会のときは、眠くて眠くて仕方がない状態だったのであまりおしゃべりできませんでした。ちょっと後悔というか残念というか。カトウさんはブクマと同じことを言ってて、あ、あの人か、とすぐにわかりました。

各社ブログでの Atom API の違い

あとで、詳しい解説記事を書きます。とりあえず、反応だけしておきます。

投稿APIとしてAtomを採用しているブログでは、セキュリティ対策のためユーザーIDとパスワードが暗号化されて送信されますが、その暗号化の方式が複数通りあるのが困り者なのです。
Web版のRSSリーダー兼ブログエディタfeedpathの対応ブログサービス一覧表
によると、Atom APIを採用しているブログの中には認証方式が違うものが3種類あります（Blogger以外はすべて日本のブログサービス）。
Blogger：basic
Livedoor ：wsse2
So-net：wsse2
ameba：wsse3

これで見る限りはLivedoorとSo-netは同じユーザー認証方式を採用し、その結果同じ方式で暗号化を行っているはずなのですが、ectoでLivedoorに書けてもSo-netには書けなかったことから実際には暗号化方式が違うことがわかります。
Mac-de-cocolog: Mac版ブログ投稿ツールとAtom API

確かに認証方式だけで見れば、以下の3種類(細分化すると5種類)あります。

blogger 方式: BASIC認証 (+ https) [現時点では http でも https でもどちらでも OK。将来は https のみになると思われます]
- 従来の方式: blogger のユーザ名とパスワードを使って BASIC 認証
- Google GData API 方式: blogger のアカウントと紐付けられた Googleアカウント(メールアドレス)とそのパスワードを使って BASCI 認証(login)して、3種類の識別用コードを取得し、以後は、その識別コードを使ってアクセス
古典的な方式: WSSE認証 (TypePad, livedoor Blog, LOVELOG, So-net Blog など)
- TypePad, livedoor Blog, LOVELOG: blog の管理画面に login するときのユーザ名(あるいはメールアドレス)とパスワードを使って WSSE 認証
- So-net Blog: Atom API で投稿するための専用パスワードを取得し、それを使って WSSE 認証。ユーザ名は So-net に login するときのユーザ名ではなく、So-net Blog の方で別途設定したユーザ名(blog のユーザ名)を使用する。
独自方式: WSSE認証 (アメーバブログ)
- WSSE の生成方法がアメーバブログ独自のもの (たぶん、WSSE の仕様書のどこかを誤読したまま実装してしまったものと思われる)

実際は、認証方式以外にも細々とした差異があって、その辺を全部考慮すると、Atom API (Atom Publishing Protocol) の実装方式の種類は無数に存在し得ます(というか、その辺を許容する仕様になっています[さすがに、アメーバブログのは仕様的には許容されないと思いますけど、すでに世の中に出ちゃってるので、クライアント側は対応せざるを得ない訳ですが])。

ということで、大雑把な説明をしてみました。さらに詳しい説明はあとで(気力があったら)書きます。

あと、blog 以外でも、「はてなブックマーク」のように Atom API をサポートしているサービスもあります。ほとんどの場合、上記で言う「古典的な方式」を採用しています。

[観] Vox の Atom API
Vox は Vox で TypePad とは違う実装になってるんですよね…… 認証は「古典的な方式」(WSSE)なんだけど、それ以外のところで、いろいろ違ってます。

追記

「Mac-de-cocolog: Mac版ブログ投稿ツールとAtom API」で紹介されている「feedpath - Blogエディタ対応表」というのを見てみましたが、嘘がちらほら。

Atom API のところは一律「※APIがATOMのものについてはAPI規格仕様によりトラックバック許可、コメント許可、追記、日付の設定ができません。」と書いてありますが、少なくとも「日付の設定ができない」というのは嘘でしょう。あと、blogger は(GData API の方を使えば)「コメント許可/不許可」の設定もできます。
LOVELOG は「movabletype」ではなく「Atom」です。
MSN Spaces が「ブログ側に機能がありません」になってますが、XML-RPC API (metaWeblog API) をサポートしています。

あと、livedoor フレパ と ドリコムブログ が「サイト側の事情により不可」になってるのが非常に気になる。「サイト側の事情」って何だろう?