お問い合わせ
会社概要 ソフトウェア 開発ブログ サポート

2008年03月02日

マイクロソフト - 「これからはAtomPubでいきます」

MicrosoftがWindows Liveサービス群向けに、開発プラットホームのプロトコルとして、AtomAtomPubに注力していくと発表しました。日本語ソースでは、Google Newsで検索した限り、唯一CNetでさらっと触れられていただけで、まだあまり話題になっていない様子。

 Treadwell氏はまた、Microsoftは一部のホステッドサービスにAtomインターフェースを提供することによって、「Atom Publishing Protocol(Atom出版プロトコル)」に対するサポートの充実を図っているとも語った。

http://japan.cnet.com/news/media/story/0,2000056023,20368443,00.htm

大手企業では、言わずと知れたGoogleが既にGDataAPIとして、完成直前のAtomPubから派生(現在AtomPub仕様に軌道修正中)させたAPI群を提供しており、現在までAtomから少々距離を置いていたMicrosoftが、ここに来て発表するのはちょっとびっくりでした。(Microsoftのことだから、いつ何か捻くれたキックが飛び出してくないとも限りません。"the devils in the details"と言いますからね;-) 

もしかしたら、これはある意味、SOAPへの死亡宣告になるのかもしれません。

しかしながら、このMicrosoftの動きがGoogleの時のようなモメンタムを得られるか、というと、どうかなとも思います(*1)。理由は色々ありますが、そもそもMicrosoftのWeb API とか言ってもピンとこないケースが多いんじゃないなかと。米Yahoo買収してこの分野に入ろうとは苦労しているようですが...。
(*1)但し、今回発表された、ADO.NET Data ServicesのAtomPubサポートにより、企業ネットワークでは裏方で利用が広まる可能性がある。

日本では、先日、AtomPub Interop 2008 Tokyoが開催されました。NTT Communications某氏がホストをしてくださり、参加者はNTT、リコーなどから集まり、非常に有意義なInterop(相互接続実験)でした。私は一応、Fudeを持参させていただきました。(その後で食べた餃子は結構美味しかったw)

http://teahut.sakura.ne.jp/b/2008-01-30-1.html
http://blogs.ricollab.jp/webtech/2008/02/atompub_interop/

とりあえず、今回の発表の原文から、直訳及び意訳。

Atom Publishing Protocol (AtomPub) as the future direction
将来的な方向としてのAtomPub(Atom出版プロトコル)

Microsoft is making a large investment in unifying our developer platform protocols for services on the open, standards-based Atom format (RFC 4287) and the Atom Publishing Protocol (RFC 5023). At MIX we are enabling several new Live services with AtomPub endpoints which enable any HTTP-aware application to easily consume Atom feeds of photos and for unstructured application storage (see below for more details). Or you can use any Atom-aware public tools or libraries, such as .NET WCF Syndication to read or write these cloud service-based feeds.

 In addition, these same protocols and the same services are now ADO.NET Data Services (formerly known as “ Project Astoria”) compatible. This means we now support LINQ queries from .NET code directly against our service endpoints, leveraging a large amount of existing knowledge and tooling shared with on-premise SQL deployments.

マイクロソフトは、オープンな標準(規格)ベースのAtomフォーマット及び、Atom出版プロトコルを用いて、我々の種々のサービスで用いる開発プラットホームプロトコルを統合すべく、大きな投資を行っています。今回のMixにて、AtomPubを活用する、幾つかの新しいLiveサービスを有効にし(発表し?)、HTTPを解するどんなアプリケーションでも写真や非構造的?アプリケーションストレージのAtomフィードを活用できるでしょう。(省略) AtomPubをサポートする、ADO.NET Data Servicesで、LINQ to Atom(省略)

..

Application Based Storage

Application Based storage is an experimental API which allows application developers to store a small amount of state/configuration data in the Windows Live data centers on behalf of a user. This API has an AtomPub service end point so developers will be able to call this using ADO.NET data services or other AtomPub compatible tools. The real value kicks in here if an application was to have hundreds of thousands of users as the client bandwidth and storage are offloaded to Windows Live infrastructure. 

The service and documentation will be available next week.

アプリケーションベースのストレージ(Application Based storage)は、実験的なAPIで、アプリケーション開発者が、ユーザーのために、少々の状態または設定情報をWindows Liveのデータセンターに保存できるようにする、というものです。このAPIは、AtomPubのエンドポイントを提供しているので、開発者は、ADO.NETデータサービスや他のAtomPub互換ツールを使ってこのAPIを呼ぶことができます。(一行省略)

サービスとドキュメンテーションは、来週公開されます。

...

Windows Live Photo API (CTP Refresh with AtomPub end point)

The Windows Live Photo API allows users to securely grant permission (via Delegated Authentication) for a third party web site to create/read/update/delete on their photos store in Windows Live. The Photo API refresh has several things which make it easier and faster for third parties to implement.

  • Third party web sites can now link/refer to images directly from the web browser so they no longer need to proxy images, and effectively save on image bandwidth bills.
  • A new AtomPub end point which makes it even easier to integrate.

The service and documentation will be available next week.

Windows Live フォト API は、安全にサードパーティのウェブサイトに権限を与えて、Windows Live へ写真を追加、読み出し、更新、削除を行えるようにします。フォトAPIは、サードパーティの開発者が、より簡単にすばやく実装できるように、幾つかの特徴があります。

  • サードパーティのウェブサイトから、直リンク出来ます。
  • AtomPubにより、より簡便な相互運用が可能

サービスとドキュメンテーションは、来週公開されます。

http://dev.live.com/blogs/devlive/archive/2008/02/27/213.aspx

 

投稿者 BlogWrite担当 : 05:50 | コメント (0) | トラックバック

2007年12月10日

AtomPub クライアントのベータ公開

次世代Web標準プロトコルなる、Atom Publishing Protocol (AtomPub) の、(汎用・テスト用・開発用)Clientソフトを公開しました。というか、なんとか公開にこぎつけました。

基本的には、こちらの英語版のページで更新情報を発信していく予定です。AtomPubを利用したウェブサービスの開発の助けになれば幸いです。

 

投稿者 BlogWrite担当 : 15:02 | コメント (0) | トラックバック

2007年09月08日

久しぶりにAtomの話題 - WordPressが第一号か

AtomPub(aka 「Atom出版プロトコル」)はほぼ完成した訳ですが、まだなかなか正式な実装が無い状態が続いていました(Google のGDataはちょっと別として)。 しかし、今月下旬公開予定のWordPress 2.3でついに、AtomPub正式対応を果たすようです。

WordPress 2.3 beta 1 has significantly upgraded support for the Atom Publishing Protocol. - WordPress 2.3 ♥ AtomPub


Anyhow, WordPress 2.3 is going to be a first-rate Atom Protocol sever. - Long-Weekend Fun

実は、Atomプロトコル用のライブラリを秘かに開発していて(元はここで公開していたもの)、これを使ってそろそろ色々とソフトウェアを公開して行きたいなぁと思っています。

投稿者 BlogWrite担当 : 21:13 | コメント (0) | トラックバック

2006年12月29日

The Atom Publishing Protocol ドラフト12

The Atom Publishing Protocol(Atom出版プロトコル) のドラフト12が出ました。ドラフト10ぐらいで完成するかと思ったのですが、長引いてますねぇ。

まだ内容は詳しくは把握していないのですが、そろそろ、ドラフト10をベースに作った、Atomicクライアントもアップデートしなくちゃならないし、不動産物件検索CGI - REPS も、Atom出版プロトコル対応の作業始めたいし、将来的には、Atomicで作ったコードをBlogWrite にも反映させて行きたいし...と色々大変です。

BlogWriteに関しては、Atomicで処理をコンポーネント化しているので、 これを使う予定です。

//Atomクライアントのオブジェクト
AtomClient := TAtomClient.Create(self);

//Atomクライアントの設定して
AtomClient.Username := 'hoge';
AtomClient.Password := 'hogehoge';
AtomClient.AuthType := atNone;
AtomClient.IntrospectionUri := 'http://example.org/atom';

//サービスドキュメントを取得
AtomClient.getIntrospection();

//introspectionオブジェクトが返るので、一番はじめのワークスペース内の、一番はじめのコレクションへ投稿する為の、URIを選びます
Href := Introspection.Workspaces[0].Collections[0].Href

//エントリのオブジェクト
AtomEntry := TAtomEntry.Create;

//エントリの設定
AtomEntry.Title.Text := 'タイトル';
AtomEntry.Content.Text := '本文';

//エントリの投稿
AtomClient.postEntry(Href, AtomEntry);

//結果成功であれば、エントリのオブジェクトが返り、AtomEntry.editUri に投稿(Put)すれば編集、Deleteすれば削除も出来る。
AtomClient.updateEntry(AtomEntry.editUri, AtomEntry);
AtomClient.deleteEntry(AtomEntry.editUri);

といった感じ...

C#や、Javaでも、Googleが提供しているライブラリを使えば、似たような感じで出来るのではないかと思います。

投稿者 BlogWrite担当 : 15:39 | コメント (0) | トラックバック

2006年08月17日

RESTにおけるベストプラクティス: エラーハンドリング

RESTfullなAPIにおいてのエラーハンドリングについては重要なのですが、今まで(特に日本では知っている限り)あまり言及されたことがなさそうなのと、オライリー系のサイトでたまたま今日良い記事 RESTful Error Handling を見つけたので、ココで紹介したいと思います。 (2003年12月の記事ですが何故か見落としていました)

この記事では、REPSfullなWebアプリケーションにおいて、エラーが発生した時の動作は(調査した所)一般的にいって4っつの方法が利用されているとしています。

1.HTTPステータスコードのみ

例えば、

http://www.example.com/xml/book?id=1234&dev_token=ABCD1234
のようなアドレスでGETした時、もし"id="によって指定されたデータが見つからなかった場合、HTTPステータスコードの404 Not Found を返す、といった具合。

2.空のレコードセットを返す

例えば、Atomフィードを返すようなケースで、エントリが一つもないフィード空フィードを返す。この場合、そもそも不正なIDなのか、単にまだ存在しないのかなどは分からない。 

3.HTTPヘッダーを拡張する

HTTP/1.1 200 OK
...省略...
X-DAS-Status: 403
Content-Type: text/plain
Content-Length: 10
Date: Sun, 30 Nov 2003 21:02:13 GMT

上記のように、HTTPヘッダー内にアプリケーション固有のエラーコードを埋め込む。(注:確か偉い人がX-**のような拡張は安易に行なうべきではない、といった事を言っていました)

4.XML文書を返却する

<?xml version="1.0" ?>
<xoomleError>
   <method>doGoogleSearch</method>
   <errorString>Invalid Google API key supplied</errorString>
   <arguments>
     <hl>en</hl>
     <ie>ISO-8859-1</ie>
     <key></key>
     <q>oreilly php</q>
   </arguments>
</xoomleError>

のようなXML文書を返却して、エラーの詳細を通知する。

RESTにおけるベストプラクティス

ではRESTベースのWebサービスではどの方法がベストプラクティスと言えるのでしょうか、と筆者は問いかけ、未だベストプラクティスといえるものは無いようだと述べています。

しかし、もっとも重要なのは、「人間が読めるエラーの説明文」、「アプリケーション固有のエラー」、「機械処理できるエラーコード」であり、この三つのカテゴリを含む、少なくとも下記の条件を満たすのが大事なんじゃないかと述べています。

  1. HTTPステータスコードはHTTP通信に限ったエラーのために用い、アプリケーション固有のエラーには用いない。
  2. エラー発生時には、必ず詳細を含んだXML文書を返却する。
  3. XML文書にエラーコードと共に人間が読めるエラーメッセージを含めよ。具体的には下記の例:

<?xml version="1.0" encoding="UTF-8" ?>
<error>
  <error_code>1001</error_code>
  <error_msg>不正な Google API キーです。</error_msg>
</error>

これを実践することによって、Webサービスは利用側の苦労は軽減し、問題が起きた時の対処も楽になる。エラーコードを元に適切な挙動をする事も出来る。

記事は大体上記の感じです。最後のまとめ部分は、100%同意する所です。以前、関連する事を、REST原理主義という微妙な記事で書いてしまいましたが、元々はAtom Publishing Protocolのワーキンググループ内での議論がきっかけでした。

個人的にAtom Publishing Protocolでエラーハンドリングのことが何も決まっていないのは問題だと思い、エラーフォーマットを提案していたのですが、大体において反応は、あると便利(4.XML文書を返却する)というのが多数、あるべきというのは少し、無いべき(1.HTTPステータスコードのみ )というのが少数だが激しく、という感じで結局、仕様には含めない、という事になっています。(このワーキンググループでは、異論があるのは本仕様外とする、という傾向が常々指摘されているw)

つまり、

「人間が読めるエラーの説明文」: なし(追記:正確にはリスポンスのボディに何かが返される場合がある。何かは極端な話×印の画像かもしれない。文字列だとしても、JSONかもしれないし、XMLかもしれないし、ただのテキストかもしれないし、Base64エンコードされているかもしれない。さらには文字コードの判定と変換といったWebブラウザ並の処理の手間がかかる。もしこれが特定のXMLフォーマットが返ると決まっていれば、これらの問題と手間はすべて解消される)

「アプリケーション固有のエラー」:: なし(追記:正確にはHTTPステータスコードで間に合わせる)

「機械処理できるエラーコード」: HTTPステータスコードで間に合わせる

という残念ながらベストプラクティスとはかけ離れたものとなってしまっています。最終的な希望は、Atomのコア仕様に含まれなくても、拡張仕様として後付けできるという事で、今後の試行錯誤で何らかのフォーマットが出来て、それにまとまっていくことが考えられます、というか強く希望しています。

なお、ホンモノのRESTベストプラクティスを読みたい方は、こちらのスライドをどぞ

投稿者 BlogWrite担当 : 15:31 | コメント (0) | トラックバック

Blogger + GDataとoptimistic concurrencyなど

Bloggerのブログがアップデートを控えてベータ版が公開されています。主な変更は、

  • GMailでメールにラベルをつけるのと同じように、記事にラベルをつけられる。(カテゴリの感覚)
  • 記事を誰が読めるか指定出来る(Voxと同じ方向性)
  • マウスのドラッグ&ドロップでレイアウトを変更

など。ここで新機能の紹介と、日本語のニュース記事は、ここや、ここ。 今後徐々にベータ版に移行できるようにしているそうです(現在移行できるブログに制限がある)。

感覚的には、日本ではあまりBloggerは利用されていない感じがして身近にインパクトはありません。ただし、GoogleのGDataAPIに関する動きの一環として、今回のベータ版からGDataAPIを利用した投稿が出来るようになったのが興味あります。

GDataAPIと言えば、新しいAtom Publishing Protocolベースの規格で、今の所、Googleカレンダーそして今回のBloggerで使えるようになりました。(Google Baseで使えるようになるのが待ち遠しい..)

Bloggerでの利用方法と詳細は、Using the Blogger Data API

個人的な感想としては、Atom Publishing ProtocolベースのGDataAPIといっても、一癖ある感じです。特に、AtomicとIBM系のAtomサーバー実装などで行なったテストなどと比べると幾つか面倒な点がありました。

一つは、GDataAPIの独自のクセのある認証方法、もう一つはoptimistic concurrency (OCC)。 Googleを皮切りに、IBM系のシステムでもこのOCCを検討しているらしい...。と同時に、一部で議論になりつつもあるのがOCC。

意図しない上書きなどによる、データの誤った喪失を防ぐにはOCCは安易な方法だけれども、万が一、かち合った(conflict)場合の処理方法(DiffとMerge)、を考えると現実的ではないし、第一ぜんぜん楽しくない。例えば、バージョン管理システムのSVNでConflictがあると、「エーイ面倒くせーい、一旦全部削除してしまえ」という事がたまにあるのだけど(ほんの稀にですw)、それと似た感じ...

最悪なのは、記事を編集して投稿したら、Conflictが起きたので、今のは破棄するか、最新の記事を取得し直して一から書き直してください、見たいな事が起きてしまう事ですよね...。

他の方法としてはClient-ServerデータベースアプリケーションでよくあるLock。これだと、某ユーザーがアクセス中なので変更出来ません状態に陥ってしまいます。なので、多くの場合、後勝ちの方法で、最後に更新されたデータで上書きされる、というのが現実的に採用されています。多分現在のブログは、この後勝ち。どれもそれぞれ欠点というか問題があります。

カレンダーアプリケーションのようなケースでは良いですが、その他のケースでは個人的には、安易に特定の仕組みを導入するよりかは、実装と運用方法でカバーするのがベストのような気がしますが、もうちょっとこの件追っかけて行きたいと思います...。

投稿者 BlogWrite担当 : 12:52 | コメント (0) | トラックバック

2006年04月20日

AtomプロトコルのGoogleグループ作りました

前エントリでチラッと追記したのですが、先日勢いでThe Atom Publishing Protocol に関するGoogleグループ (Atom Protocol -ja) 作りました。

このブログでAtomのことばっかり書くのもアレですし、ここまで来たらしょうがないという事で、Atom関連の技術を日本語で気軽に情報交換をするためのグループです。

Google Data APIs Protocol や Lucene Web Service API のように、The Atom Publishing Protocolベースの新プロトコルも出てきましたし、新たなプロトコルも出てくるでしょう。気が向いたら本家MLの細かい最新動向とかも流すかもしれません。気軽にご参加ください。 NDOメソッド で。

投稿者 BlogWrite担当 : 21:02 | コメント (1) | トラックバック

Atomベースの Google Calendar Data API公開

Google Calendarが先日公開されて大変便利に使っているわけですが、このカレンダー情報を外部アプリケーションから更新するプロトコルが公開されました(はてブ経由ogawaさん経由)。

Google Data APIs Protocol (GData)というのが、今後Googleで汎用的に使われるベースとなるプロトコル。そして、このGoogle Data APIを利用した、Google Calendar 向けの仕様が、 Using the Google Calendar Data API という事らしいです。

iCalベースとかだろう、とたかを括っていたら、中身を見てビックリ、The Atom Publishing Protocol+OpenSearch。それに、現時点ではまだ The Atom Publishing Protocolで規定されていないCategoryや、APPとは別仕様で採用する予定だった全文検索や更新されたエントリーのクエリー方法まであります。

The Atom Publishing Protocol ベースなので、当然RESTです。

興味深かったのが、Account Authentication for Installed Applications という、インストールするアプリケーション用の認証方法も公開されていることです。「TypeKeyとWeb APIの(ちょっとした)落とし穴」で書いたデスクトップ上のアプリケーションからの認証もしっかりと考慮してくれている所がステキです。Proxy Authentication for Web Applications っていうWebアプリケーション向けの外部認証システムは未だ未公開だけど別途用意するようです。

今後、GoogleはGoogle Calendarのみならず、Bloggerやその他のサービスでも、(旧AtomAPIでなく)この The Atom Publishing Protocol ベースの利用をガンガンおしていくんではないかと思います。

The Atom Publishing Protocol (現在ドラフト08版) 対応の相互運用性テストクライアントを、ここで公開しています がそのままではGoogle Calendarで使えないっぽい(認証とかIntrospectionとか)ですが、これ用に作ったDelphiのAtomライブラリを利用すれば、簡単にCalendarクライアントが書けそうです。

因みにGoogle謹製のJavaとC#ライブラリも公開されてます。でもHTTP+XMLなんでどんな言語でもOKです。早速PerlライブラリがCPANにアップされる予感します。

追記:
Atom 1.0に対応したPerlライブラリとしては、XML-Atom-Syndication なんかがあります。でもプロトコルの方はまだ仕様が固まっていないのでまだプロトコル向けのPerlライブラリは無いようです。因みに、The Atom Publishing Protocol draft-08に対応したサーバーとクライアントの一覧は、先日Wikiページ AtomPubTesting に作成されてますので、ご興味のある方は是非。

で、想定される用途としては、CRM(顧客関係管理)ソフトウェアやプロジェクト管理(BaseCampAPIと連携して)から、打ち合わせ日時や〆切りを入力したら同時にGoogle CalendarにもEventを登録して...などなど色々とやって見たくなります...。あ携帯用クライアントとかも需要がありそうですね。

追記:そういえば、先日勢いでThe Atom Publishing Protocol に関するGoogleグループ (Atom Protocol -ja) 作りました。毎度ですが、勢いです。

投稿者 BlogWrite担当 : 18:56 | コメント (0) | トラックバック

2006年03月27日

Re: MT 3.2のAtom API

トラックバック頂きまして、MT3.2でのAtomAPIがBlogWriteで正しく動いていないという事気が付きました。MT3.17では、問題ありながらもとりあえず動いていはいたんですが...。

結論から言うと、MTでの利用に限って現時点では今まで通りXML-RPC APIを使って頂きたい、という所です。(過去の経験からTypePad含むMTのAtomAPIは日本語周りとか色々問題があったため)

けれども、MTでAtomAPIが動くに越したことはないので、Ogawaさんの方法で、MTのAtomServer.pmの一行をコメントアウトして、動作検証して見た所、Ogawaさんのご指摘どおり、過去記事の取得を除けば、日本語周りも含めて動くようになりました。

で、なぜ過去記事の件が取得は出来ていながらBlogWriteで上手く行かないのか、という事ですが、

例1: 
<content mode="xml">
   <div xmlns="http://www.w3.org/1999/xhtml">asdfasdfasdf</div>
 </content>

コンテンツのmodeがXMLとなっているのですが、コンテンツのTypeが指定されてないため、デフォルトのtext/plain扱いになります。で実際はDIVで括ったXHTMLなので、Text扱いすればよいのかXHTML扱いすればよいのか分からず正しく編集出来ません。なので下のように、XHTMLなら、"application/xhtml+xml"のように指定するのが吉。
 
<content mode="xml" type="application/xhtml+xml">
   <div xmlns="http://www.w3.org/1999/xhtml">asdfasdfasdf</div>
 </content>

例2:
<issued>2006-03-06T13:41:18+0900</issued>

日付変換処理で落ちまくっている、と思ったら、MTが返す日付が上記のように、タイムゾーンオフセットが、+0900になっていました。RFC3339の仕様、詳しく読んでいないけれど、普通は、下記のように、コロンが必要なんではないかな、と思います。ここで落ちているため、処理が止まってしまってました。

<issued>2006-03-06T13:41:18+09:00</issued>

あともう一つ。日本語のコンテンツがすべてBase64でエンコーディングされている気がします。確かに仕様ではBase64指定出来るとあるけれど、これは本来バイナリーのアップロードに使うものじゃなかったのかっ?というツッコミも一応。BlogWriteは一応Type属性でtext/htmlとか,plain,xhtmlに指定されてた場合のみ、Base64もデコードしてます。

参考:旧AtomAPI仕様ドラフト

で、一応なんですが、そろそろ、この旧AtomAPIはObsoleteになりつつあります。 ベンダーとしては、今この旧AtomAPIにリソースを割くよりは、現在IETFで議論されている、The Atom Publishing Protocol のサポートに注力すべき頃だと思います。
参考:
The Atom Syndication Format (RFC4287),
The Atom Publishing Protocol (draft-08)

IETFワーキンググループでの現状ですが、今はAtomPPのクライアントとサーバーによるInterop(相互運用性)テストを行なっているフェーズで、この結果を元にさらに、仕様をリファインしていく段階です。もうすぐ仕様は完成か、と言われると、微妙です...。大体出来たけど、まだまだやること残っている、といった所でしょうか。

当然のことながら、BlogWriteでもこのAtom Publishing Protocolをサポートすべく、積極的に動いたり、IETFでのMLとかでも最近はアクティブに参加してます。

投稿者 BlogWrite担当 : 14:10 | コメント (0) | トラックバック

2006年03月06日

RESTなWebAPIの開発支援ツール

技術者向け記事です。ご興味ない方には申し訳ありません。

ちょっと前になりますが、RESTのAPIを開発する上で便利かもしれない社内製ツールを公開しました。5年ぐらい前に学習目的で作ったXMLエディタとBlogWriteの通信部分をくっつけてゴニョゴニョとやったものです。

因みに、「The Future of Web Apps」 Webアプリの未来 - と題したコンフェレンスのポッドキャストをやっと消化し終わりました。

このコンフェレンスでは、Googleマップの開発者、米Yahooの人、Ruby on Railsの人、Delicious、Flickr、などなど最近の代表的Webアプリケーション開発者が集まった豪華なメンバー..。どの話にも共通していたのは、やっぱり、APIの事でした。OpenなWebサービスAPI重要。

The Atom Publishing Protocolもある程度形になってきましたし、日本でもRESTについて、APIについてそろそろ盛り上がってきたこの頃、皆様いかがHackしておられますでしょうか。

自分がAPIのサーバー側を作ることになって気が付いたのが、API自体の設計や開発、テストをする上で面倒な事は、サーバー側のアプリケーションとクライアント側アプリケーションを両方作らなければならない、という事でした。サーバー側を作ってテストするには、クライアントも同時に作らないと行けません。インターオペラビリティを確保するためにも、第三者が作ったクライアントがあった方が良いです。ところがクライアントは、世の中に存在していないAPIに対応したり、サーバー側アプリケーションが動いていない中ではどうしても作りにくいものです。まさに鶏と卵。

では、汎用的なRESTfull APIクライアントがあれば、Web APIを実装する際、特にサーバー側で実装する際、色々と便利ではないでしょうか。ブラウザではGETは出来てもPUTやDELETEは出来ませんし、ヘッダー周りや内容を変更する事は難しいです。

そこで、POSTやPUTする場合、Bodyに含めるXMLを予めファイルで用意しておけば、後は随時、任意のXMLを開いて一発で指定したメソッドでHTTPリクエストを発行し、ヘッダを含むレスポンスも確認出来るようにしました。ついでにXML編集機能がありますので、設計段階から使えます。

もともとXMLエディタだったものをベースにしているので、POX(Plain Old XML)の作成編集、XSLTの作成編集プレビュー機能などもあり、Atom,RSSのGET、AtomAPI(GET,POST,PUT,DELETE)のテスト、XML-RPC(POST)のテスト、OPMLも直に読み書き(GET,POST)できるようにしました。

XMLを脳内変換出来る人はこれだけで、ウェブのRead/Writeが実現(w)、ブラウザいらず..というのは冗談です。

もしご興味がありましたら、
http://www.witha.jp/eXeries/ja/
からご自由にどぞ。 

追記:(2006/03/09)
英語版のページも作っておいたら、早速「ある本の著者なんだけど、スクリーンショット使ってもいいか」なんてメールが海外から来ました。楽しみ。

投稿者 BlogWrite担当 : 19:52 | コメント (0) | トラックバック

2005年12月10日

[フィードとは] 日本語版作りました

 かなり前になりますが、http://xml.feeds.jp/ というドメインを個人的に勢いで取っていたのですが、特に使い道が見つからず、ずっと寝かしたままになっていました。で最近、IE7でWeb Feedsという名称を使うとかなんだかで、注目されてきて、何か有意義な利用方法がないかとずっと思っていたのですが、時間も無いので放置してたという訳です。

で、本日仕事でMT3.2のブログのテンプレートを弄っていたら、下のような[フィードとは]というリンクがあって、RSSやらAtomフィードの説明リンクがありました。ところが、リンク先が米SixApart社のサイトのページで当然ながら英語です。

このブログのフィードを取得
[フィードとは]

これでは親切ではありません。ちょっと検索しましたが、中々適当な替わりのサイトが見つかりません。そこで、 http://xml.feeds.jp/ に、サクッと作って見ました。もし同じようなことで悩まれたことがあればご自由にご利用ください。

まったく個人で保持しているドメインなので、商業サイトとして利用するつもりもありません。無保証ですが、大した維持費用もかかってませんので、近い将来急になくなるとかはありませんし、他の用途に用いる予定も今の所まったくありません。

内容的なフィードバックは、とりあえずこのエントリのコメントでお願いいたします。

投稿者 BlogWrite担当 : 17:09 | コメント (3) | トラックバック

2005年12月06日

Atom FormatにRFC番号がついた

ついに公式なIETFのRFC4287、 The Atom Syndication Format となったです。プロトコルの方の完成は近くって遠いという感じでしょうか...。あ、本書かなきゃ...。

投稿者 BlogWrite担当 : 15:20 | コメント (0) | トラックバック

2005年11月28日

BlogWriteでの過去記事取得(というか同期)について

BlogWriteに関していただく最近一番の要望は、過去記事の取得に関する事です。(ここここここ、など)

大別すると、下記の二つになります。

1.BlogWriteを使い始める前からの記事も全てBlogWriteに取り込みたい。
2.別のPCやウェブ管理画面からの投稿した記事もBlogWriteに取り込みたい。

非常に良く分かりますし、是非実装したいと思っています。が、どうしても気になることがあります。

もし普通にアクセスして、全過去記事を取得して取り込むとすると、サーバーにかなりの負荷をかけるのです。具体的には、100の記事がある場合、BlogWriteは100回+1回の計101回の連続アクセスをする事になります。これはまずいです。DoS攻撃並。レンタルサーバーによっては極端な負荷をかけるスクリプトを停止することもありますので、これもまずいです。101回のアクセスで数秒の間を空けることも出来ますが、101回だったら結局全ての処理に長い時間がかかってしまいます。

以上のような懸案があって悩んでいる中、先日のXML開発者の日にSixApartの某氏と雑談の中で、結局IMAPのような仕組みが必要かも、とか、Atomフィード形式でエクスポートしたものを取り込めば…なんて会話がありました。

例えば、記事の「タイトル」、「最終更新日時」、「メインカテゴリ」、「記事のIDもしくはEditURI」、最低この四つの項目さえ取れれば、ローカルのログの時刻と比較して、必要に応じて記事をサーバーから取得する、という事が可能になります。この仕組みであれば、結構上手くいくのではと思います。

問題は、現在の所どのブログサービスもそういった一覧を取得出来るようにはなっていないことなのですが...。 何か対策、ご意見、賛同者、例、などございましたら是非ご一報くだされば嬉しいです。

 

追記:
「MovableTypeであれば、“エントリの書き出し”で同じことが出来るのでは」という御連絡をいただきました。

Movable Typeだけに対応するのであれば、確かにMTから書き出したものを解析すれば良いのですが、他のブログのフォーマットにも一々対応するのは現実的ではない、など色々ありまして、(他にも例えば、Perlなどのようなスクリプト系言語での強力な正規表現が楽に使えない環境もあれば、文字コードやら改行コードの判定が難しい環境もあるでしょう)

出来れば汎用フォーマット規格であるXMLで、なお且つ、元々ブログのアーカイブ(保存)フォーマットとして作られた、Atomフォーマット形式であれば、完璧かな~という所です。

さらに言うと、内輪規格はできるだけ避け、汎用的で標準的規格を採用するべきではないか、と思っています。例えばSixApartと私で独自フォーマットを決めちゃって、結果として他者(の利用など)を排除するようなクローズドな仕様はキライです。もしそういう事を他でされたら私なら文句を言います

投稿者 BlogWrite担当 : 21:42 | コメント (6) | トラックバック

2005年11月16日

不動産物件情報とXML(Google Base)

Google Baseが(英語版)ですが公開されたようです。 (以前の記事

興味があったのは、データのアップロードのところで、タブ区切りテキスト、とXML(RSS、Atom)でのデータアップロードが可能なようです。

そこで、前々から言っている、XMLによる不動産情報の記述にとても興味をもったので詳しく見てみました。不動産情報というのは、国ごとに異なるため、そのまま全世界で使うのは難しいのではと思っていますが、Google Baseは世界展開するわけで、日本でも初めての不動産情報のXML記述として利用されるということになるので大変興味と関心を持っています。

さらに、つい先日公開した、不動産物件検索エンジンCGIでも、物件情報の配信としてRSS、Atomでの配信を予定しており、その仕様を考えていたのでまさにタイムリーです。

実は、かれこれ4、5年ほど前に日本の慣習と法律に合った不動産物件情報のXML定義(スキーマ)を提案、公開し、専用サイトも作りましたが、まぁ時期が早すぎたのか、業界の団体関係者の反応はそれはそれは冷たいものでした。

ともかく、Google BaseのAtomのXML拡張(Google Base - Atom 0.3 Specification)を見てみると、下記の拡張が定義されていました。 (追記:なんでAtom1.0ではないんだろう...。)

Housing - properties for sale or rent
agent, area, bathrooms, bedrooms, expiration_date, hoa_dues, label, listing_type. location, price, price_type, payment_accepted, payment_notes, property_type, tax_region, tax_percent, year

これだと、日本ではやばいですね。広告規定みたいのがあって、これこれの表記をすべし見たいなのに引っかかりますし、日本では意味のない項目もあります。

どうするんでしょかね、とか他人事のようにいってますが、近いうちに以前作ったスキーマでも公開します。

関連記事:
不動産情報とXML
Atomプロトコル (Atom API) の可能性:不動産業界での例
ライブドアがフランチャイズ不動産事業参入、不動産とRSSエトセトラ

投稿者 BlogWrite担当 : 16:49 | コメント (0) | トラックバック

2005年10月26日

BlogWriteでLivedoor Blogでの画像投稿

Livedoorの新環境移行が済んで以来、LivedoorBlogで画像が追加出来るのか出来ないのか中途半端な状態が続いていました。
参照:BlogWriteからSo-net blog、Livedoor blogへ画像の送信(未遂)

ひょんな事から、今テストした所、BlogWriteからLivedoorBlogへ、画像付き記事を投稿することが出来る事を確認しました。何はともあれ良かった。

 

投稿者 BlogWrite担当 : 19:49 | コメント (0) | トラックバック

2005年10月22日

Atom API ≠APP

プログラミングをしている人はもとより、検索をしたことがある人は、検索語句の内、一文字でも違ったら、探している情報を探し出せない、というのを身をもって体験していると思います。ですから現在のインターネットでは名称(の統一と正確さ)は非常に重要なものです。

というか、AtomAPI、またの名をAtomPP、またの名をAPP、正式名称Atom Publishing Protocolとかいうのいいかげんに止めたい.^^;

またまたAtomなんて厄介な名前をつけてくれたなという感じですが投票で決まったのだから仕方がありません。 それにAtomだけだと、あらゆるページの「RSS、Atomフィードはこちら」へ引っかかってしまって手に負えませんし...。

ということで、IETF以前の(つまり現在の)はAtom APIで通し、IETF以降のをThe Atom Publishing Protocol(APP)と呼ぼうと思います、個人的に。つまりAtom API ≠ APPということで、ダメかな...、うーん、いやーもうどうでもよくなってきた。

で略ですが、英語の文章では、前後の文脈や場によって略すことが可能な場合と可能かどうか微妙な場合があります。例えばAtomの話をしていて前後の文脈で明らかな場合、例えばAtomのML等での文章中、または文中すでに一度正式名称を使っている場合は、APPでOK。でも脈絡もなく突然Appだと?だし、Application等々の略でもあるのでNG。

そして私以外の日本の皆さん多くに使われ始めているAtom PPという略は...、一番無難なのだけれど、個人的にはちょっと微妙。あくまで個人的に。HTMLをHyper TML、HTTPをHyper TTPみたいなので個人的にちょっと違和感あるのと、PPが目立ってしまって(「ピー」というのは米口語(一般的に赤ちゃん言葉)で「オチッコ」という意味があったりして)聞いててつい、ピーピー言いながらチビッコが駆け回っている姿が頭に浮かんで始末におえません^^; 

かといって、APIというのは実はこの場合不適切なんだそうです。アプリケーション・プログラミング・インターフェースではなく、プロトコルなので、はじめにAtomAPIと呼び始めた人が「失敗したー」と言っていましたが、もう遅すぎます。結局のところ「Atom(配信)フォーマット」「Atom(出版)プロトコル」でもいいような気がしますが、またまた別名が増えるのでこれなかった事に。

どちらにしても、Web上で書く場合は、検索エンジンに引っかかるように(つまり他の人の益のために)、面倒でも必ず一度は文頭で正式名称を書く、という風にしようと思います。

投稿者 BlogWrite担当 : 00:14 | コメント (1) | トラックバック

2005年10月21日

Feedフォーマットの歴史、バージョン、起源とか

一部でちょっとRSSというか、Syndication フォーマットというか、Web Feedsのバージョンとか歴史とか話題になってました。 確かに混沌としているのですが、簡略化すれば分かりやすくなるけれど、多くの場合、簡略化しすぎて間違いになってしまいます。

ということで、とりあえず作って見た図。 (OpenOffice2.0を使いたかっただけとも言う)

Feed-History-tm.gif 

追記:OpenOffice.org 2.0 Draw形式のオリジナルファイルのダウンロードできます。改変自由、再頒布自由。

原典(ソース)を提示するのも大事なので、以下:

MFC (Apple->Netscape->W3C)
http://www.w3.org/TR/NOTE-MCF-XML/
http://www.w3.org/TR/NOTE-MCF-XML/MCF-tutorial.html

CDF (Microsoft->W3C)
http://www.w3.org/TR/NOTE-CDFsubmit.html

scriptingNews (Userland)
http://davenet.scripting.com/1997/12/15/scriptingNewsInXML

RSS 0.90 (Netscape)
http://www.purplepages.ie/RSS/netscape/rss0.90.html

RSS 0.91 (Netscape)
http://my.netscape.com/publish/formats/rss-spec-0.91.html

RSS 0.91 (Userland)
http://backend.userland.com/rss091

RSS 0.92 (Userland)
http://backend.userland.com/rss092

RSS 1.0 (RSS-DEV)
http://purl.org/rss/1.0/spec

RSS 2.0 (Userland->Harvard)
http://blogs.law.harvard.edu/tech/rss

Atom (The Atom Project -> IETF)
http://www.intertwingly.net/wiki/pie/FrontPage
http://www.ietf.org/html.charters/atompub-charter.html

ご指摘ご意見感謝。

下記ムックでもイントロ記事で、RSS&Atomについてそれぞれのバージョンや違いについても詳しく書かせていただいてます。宜しければそちらもどうぞ。

最新WebサービスAPIエクスプロ-ラ ~Amazon、はてな、Google、Yahoo! 4大Webサービス完全攻略
Software Design 編集部
技術評論社 (2005/09/23)
売り上げランキング: 6,326
おすすめ度の平均: 5
5 Webサービスの適用事例を把握するのに大変有効

投稿者 BlogWrite担当 : 20:13 | コメント (0) | トラックバック

2005年10月18日

第八回XML開発者の日

というのが11月24日 、開催されます

RESTとAtom Publishing Protocol(AtomAPI、AtomPP、APP)を中心に、Web2.0時代を支えるRESTによるAPIや来年注目の技術トレンド話題のAtomAPIについてのイベントなのですが...。

えと、私もパネルでチョビット何か話す機会を頂きました。

なんか、はてなのNaoyaさん(アルファブロガー)とか、SixApartのhirataさん(日本のブログ界の立役者)とか、XMLの父とも言える村田さんとか、REST入門を書かれた yohei さん、RESTWiki を作った方、かの高橋メソッドの高橋さん...

そうそうたるメンバーです。

浮きそうです、というか浮いてます。

というか、AtomAPI、またの名をAtomPP、またの名をAPP、正式名称Atom Publishing Protocolとかいうのいいかげんに止めたい.^^; 

投稿者 BlogWrite担当 : 16:21 | コメント (0) | トラックバック

2005年10月14日

ライブドアがフランチャイズ不動産事業参入、不動産とRSSエトセトラ

なになに...。 ライブドア不動産が不動産仲介フランチャイズ(FC)事業開始

加盟店と顧客の双方に利便性の優れた弊社FC加盟店を通した不動産取引が増加することでが業界自体の改革および活性化につながるものと考えております。

ITと不動産業界、という点ではかなり詳しいつもりですが、ライブドア参入という影響は注目したいです。「業界自体の改革および活性化」という所がとってもステキです。個人的経験からすると、エベレスト級に大変そうですが、彼ならもしかすると....。と期待しつつ、その前にここの内容の充実が先ではないかと思ったりする。

というか、レインズなど化石時代の代物を一度解体して、ライブドアに発注して1000分の一の値段で、100倍マシなのを作り直してもらえば良いのに、とココロの中で思ったのはナイショです。

冗談はさておき、今朝がた、不動産物件検索エンジンCGI公開を書いたばかりですが、開発しながら思った事が沢山あって、例えば、大抵の不動産会社は現状、自社サイトと各種ポータルサイト、 不動産ジャパン(国交省外郭団体+業界団体運営サイト)、アットホーム、ホームズ、アドパーク、イサイズ、等々様々な場所に大抵はお金を払って物件情報を自分で登録するなどして公開している訳です(場合によってはFaxとか営業マンが足で回って集めてる)。さらにはレインズもありますが、これは物がまったく違うので別とします。

やって見ると分かると思いますが、入力作業は何気にかなり面倒です、コストもかかるし。理想は一度入力したら、あとは良きに計らえ、というものです。しかもコストをかけずに。

どうするかというと、例えば、個々の不動産会社が自社サイト上で、XML形式(またはマイクロフォーマットでも何でも標準化されたフォーマット)で物件情報を認証付きで配信し、アットホーム・ホームズ・不動産ジャパン、(ライブドア不動産でも良い)等のポータルサイトが、登録した個々の不動産会社のサイトから(RSS・Atomフィードを取得するのと同じように)物件情報を取得して、物件情報を取り込めば、個々の不動産会社は自社サイトでの物件情報だけ管理すればよくなるはずです。物件情報の内容が更新されたら更新Pingの発射です。

またライブドア社と協業で不動産の物件データにフィットするRSSデータ形式やアフィリエイト広告ビジネスとの連携などの研究に着手する。

なんて事がさらっと書いてあった記事もあって、良ければお手伝いしますよ(笑)

つまりこれは実質、現状GoogleやYahooが個々のサイトを巡回して様々なページ情報を集めているのと同じです。不動産情報の場合、項目が多いし、言語解析の誤判定は避けたいので、XML形式等での特定の規格で配信する必要がありますし、認証で保護したいという理由もあるでしょうが、そういった事は対応可能ですから、あとはやるかやらないかという問題です。

もし上記のような事が上手く実現したら、不動産業界のウェブ上での下克上が起きると思います。

もちろん一人とか一社で出来ることであればすぐしているのですが、こういうのは全体的にそういう流れになるか、大手が始めるか、(結局無理だった業界団体主導でしか)ないとは思います。そういう意味でライブドアの動きは注目したい(長い目で)。

あとは、デスクトップ上(またはイントラネット内)の物件管理DBソフトから、アットホーム・ホームズ・不動産ジャパン等のポータルサイトへ直接一気に物件情報の公開が出来るような規格(API)を公開するとか..BlogWriteがLivedoorブログ、MT、シーサー等のブログサイトに投稿出来るのと同じ按配です。色々な点で、こっちの方が良くて、前向きな会社もあったのですが、一部のサービス運営会社にはかなりの抵抗感があるようでムリポでした。。

あと、他社付け(先物、流通)物件に関しても、同様で、他社付け可の物件を自社サイトでRSS等で配信しておけば、一々FAXなど送らなくても良いし、まだ空いているかどうかを各不動産会社が電話で問い合わせてくる手間も無くなって良くなるとか。埋まったものは既に埋まった物件はサイトから取り下げないといけない訳で、電話で確認+取り下げ作業というのが大変な労力になると思います。やろうと思えばこれもある程度自動化できます。

不動産業界はかなり業界としてITに関して動きが遅れていて、逆に言えばチャンスがあると言っても良いのではないでしょうか。そういう意味でライブドアにしても、やり方次第でかなり面白いことが出来ると思います(ただし業界内の色々タブーとかを上手くなんとかすればですが)。

ご存知の通り、どれも技術的には簡単に出来る事で、同等の事は既に広く行なわれている事なのです。問題はこれを業界の人に分かりやすく説明する方法だったりしますが(笑)

追記:不動産情報と位置情報に関しても、技術的に可能だけど、上記で触れたエントリでも記述した通り、現状ムリポな一例です。

というか、この文章を最後まで読んでくださったあなたは相当な不動産Geekなこと間違いなしです。

投稿者 BlogWrite担当 : 15:53 | コメント (0) | トラックバック

2005年09月16日

最新 Webサービス API エクスプロ-ラ

050916_1652.gif 最新WebサービスAPIエクスプロ-ラ ~Amazon、はてな、Google、Yahoo! 4大Webサービス完全攻略

一足早く見本誌を頂きました。(<- 携帯で撮った写真なので汚くてすみません)

つい最近も、Web 2.0 API Reference などで一覧が公開され、WebサービスAPIが注目されています。上記サイトについて、はてなブックマークのコメントとかみても、日本のサービスは?といった反応も見られ始めている中、タイミングよく、4大Webサービスを扱ったムックが発売されます。

今すぐ、Hackできる実用APIについて、これだけの情報が、ここまでまとまった形で手に入るのは稀有な事かもしれません。それぞれのサービスのAPIの紹介とその利用方法が具体的に詳しく紹介されています。 また、AJAXやGreasemonkeyなど旬の話題も扱っていたりと、至れりつくせり...。もうヤバイです。

始めのエントランス部で、とりあえずRSSとAtomについて、そして来年のWeb開発での注目トレンドの一つとの声もある、AtomAPIについて。そのあと、各サービスのAPIへ....。

この一冊で、WebサービスAPIの面白さを実感できると思います。

投稿者 BlogWrite担当 : 17:32 | コメント (1) | トラックバック

2005年08月18日

The Atom Syndication Format 正式に完成

Atomフィード;つまりThe Atom Syndication Formatが正式にIETF標準化団体において、Proposed Standard(解説)として承認されました。長いことAtom(API)を追っかけてきましたが、おめでとうございます、という感じです。プロトコルも早いとこ完成...え?それは禁句?

The Atom Syndication Format

公式アナウンス:
Protocol Action: 'The Atom Syndication Format' to Proposed Standard

投稿者 BlogWrite担当 : 12:30 | コメント (0) | トラックバック

2005年08月12日

BlogWrite 2.3

BlogWrite 2.3へ更新いたしました。

・投稿日時を指定して投稿した場合、BlogWriteの投稿記事ログ一覧にて、指定した日付ではなく投稿した日付で並んでしまう不具合を修正。

・AtomAPIで(対応しているブログサービス・ソフトにおいてのみ)画像等のアップロードを出来るようにした。
 これにより、おそらくですがSo-netブログさんで画像等のアップロードが出来るようになったと思います参考)。現在の所把握している限りではLivedoorブログとBloggerはこのアップロード機能には対応しておりません(公平を期すと、この機能は元々SixApartの独自実装です。実装するしないはもちろん運営者の裁量範囲です)。他のサービスでも対応してくださると便利ですよね...。 追記:Livedoor新環境では一応規格的には対応している模様...

実装する側から見てこの機能の良いところは、サービスUploadURIをチェックし、そのサービスがアップロードに対応しているかどうかが分かるので実装しやすい、という事。Draft機能などは、投稿して見ないと分からないので、対応し辛い。

さらに、将来的に、IETFで策定されるThe Atom Publishing Protocol でのCollectionと基本的には似ているため、最小の変更で今後も対応しやすい。

So-netブログでの使い方は、AtomAPIを使ってみた」 で非常に詳しく解説していただいています。感謝。(解説されてますが、AtomAPI用のパスワードは管理画面で別途生成する必要があるのでご注意ください)

投稿者 BlogWrite担当 : 10:32 | コメント (0) | トラックバック

2005年08月02日

ブログ投稿APIと認知度

先日、某ブログサービスの中の人とお話できたのですが...。BlogWriteどころか、他の投稿ツール一般に関してご存知ないと、言われてしまいました。あまりのショックに引き篭もりたくなりました(笑)。

やっぱり投稿用ツールというかブログ投稿クライアントの存在自体、その認知度ってまだまだかなり低いんですね、便利さの割りに。もしテレビに出てるような有名人とかが「使ってます」って言うと人気になるのでしょうか。

ともかく、まずはブログサービスの提供者側として、投稿APIを公開する利点というものを整理してみたいと思います。

まず前提として、投稿API公開とは、標準規格(例えばAtomAPI、XML-RPC API) - などのオープンスタンダードに対応すればよい、という事。特別に「BlogWriteに対応」などする必要はありません。誤解されるケースがあるみたいですが、標準的規格に対応するだけで、どんなソフトでも使えるようになり、使うソフトはユーザーが好きに選べます。

投稿APIに対応すると良い事があるかもしれない点:

■サーバーの付加軽減と通信帯域の減少があるかも

APIを通じて投稿・編集されると、やり取りされるのは、XML形式のコンテンツなので、Webページに付属する画像データ、スタイルシート等の余分な行き来が減り、サーバークライアント間のデータ通信量が減少する傾向があります。また、オフラインで記事は編集されプレビューも出来るので、サーバー上でのユーザーの操作が減り、場合によっては負荷軽減に結びつく可能性もあります。

■ユーザーに選択肢を提供

人によってはエディタや通常のデスクトップアプリケーションで文章を書くほうを好む場合があります。また、ブラウザーで書いていて間違ってブラウザを閉じて書きかけの文章が消えたり、別ページへ移動して戻ったら文章が無い、などのアクシデントを防ぎ、ユーザーエクスペリエンスの向上を図る事が出来る場合があります。

■長く使ってもらえなければ意味が無い

ブログは日々利用されるもので、継続して使って(書いて)もらわなければ意味がありません。ユーザーに継続して毎日使いつづけてもらえるように、サクッと書けるデスクトップアプリの活用があってもよいでしょう。 もちろん、BlogWriteが持っている様々な機能(WYSIWYGモード、HTMLエディタ、雛型、表、画像サムネイル、ポップアップ....)等々の利用も出来るようになる、という利点もあります。

■オープンさのアピール、そしてサービス連携によるコミュニティの盛り上がり

ブログの定義はいくつかあると思いますが、オープンスタンダードに準拠していることが重要です。XHTMLとCSSで構成され、RSSを吐き出し、ブログのソフトもできるだけWebサービスを使って、そのAPIはオープンにする。そうすることで、誰でもそれらをつなげるソフトウェアを作ることができる。抱え込むのではなく、小さなデベロッパーが一緒にコミュニティーを作れるか、というのがブログの哲学ではないかと思います。ここ数年で革命的に伸びた新興企業の多くが、オープンスタンダードを用いて「自分」のためにシンプルに作る、というところからスタートし、そして成功しています。その意味では、韓国や一部日本のブログサイトは大企業が自分たちの独自技術で作ってしまっているので、旧態依然な感じがします。

 「Joiこと伊藤穰一氏、ブログの「今」を語る」 ITmedia:インタビュー

サービス間連携とコミュニティの盛り上がりの一例として、こうさぎなどのBlogPetによる投稿などが上げられます。

■万が一の時のバックアップ

サーバー上での問題が起きて、DB内の記事が消えてしまった、という事が万が一あったとしても、ユーザーの手元にコピーが残っていれば、ユーザーの怒りもそれほどではないかもしれません(保証の限りではありませんが^^;)。

■他のサービスに遅れない

あまり知られていないのかもしれませんが、かなり多数のブログ、特に有名且つ評価の高いブログサービスほど、APIに対応しています。投稿APIに対応していないと、一部ユーザーから遅れている、という評価を食らってしまうかも知れません。ブログのような(評価などの伝播が早い)サービスでは結構致命的かも...。

という事で今回は、サービス提供者にとって、投稿APIに対応し、本腰を入れる利点をあげて見ました。このような一見地味な機能も軽視せずに積極的、かつ本格的に対応していく、というのは大事だと思います。

 

追記:これとほとんど同時にPostされた「Open Data」に関する記事や、「Philosophy of Yes」も関連してきますね..。

投稿者 BlogWrite担当 : 13:09 | コメント (0) | トラックバック

2005年07月30日

BloggerのAtomAPIアップデートで「自動改行」「下書き」の指定が可能に

WOW! BloggerのAtomAPIがマイナーアップデートしたみたいです。

具体的には、このブログでも前々から、ここここでも、懸案として取り上げていた、AtomAPIでの「自動改行指定」問題です。Livedoorの(当時)関係者の方やBlogger、SixApartの方にもお知らせ&お願いしたりしていた件です。

今回のBloggerのアップデートでこの「自動改行指定」の指定が追加されました。

<convertLineBreaks xmlns="http://www.blogger.com/atom/ns#">true</convertLineBreaks>

Atom API Documentation for Blogger 「拡張」

(訂正)思っていたのとはちょっと違って、ユーザーの「自動改行」の指定を取得する読み取り専用の値見たいです。クライアント側が投稿時に指定するのではなく、ユーザーが管理画面で指定している設定を取得し、それに合わせてクライアントが投稿前に調整したものを送信しなければいけないようです。XML-RPCでの方法とは微妙に違いました。

という事なんですが、いかがですか?<-Livedoor BlogさんTypePadさん 早速コンタクトを頂きました、ありがとうございます。

因みにもう一つのアップデートは、以前も書いた「下書き投稿」機能です。

いずれも、他のAtomAPIサービスプロバイダーが足並みを揃えていただかないと、BlogWriteのようなクライアントも対応に二の足を踏んでしまうのです。ここは一つ皆さんWeb2.0の精神を発揮し、各ユーザーの皆さんの為にも善処をお願いしたく思います。
追記:コンタクトいただきました。期待できそうです。

投稿者 BlogWrite担当 : 08:34 | コメント (0) | トラックバック

2005年07月24日

Atom1.0のcategoryについて

観測気球さんの「Atom 0.3 から Atom 1.0 への移行」記事のcategoryの件に反応。

Atom1.0フォーマットには、エントリに複数カテゴリがある場合に並列で並べる方法があるにはあるのですが、こうしてしまうと不都合があるケースがあります。

実際、MTのデフォルトRSS1.0及びAtom0.3テンプレートでは、dc:subjectは主カテゴリ一つしか出現しないようになっています。

一エントリに複数カテゴリが割り当てられている場合に(MTの場合A-Z順に)並列してしまうと、例えばRSSリーダー等でListViewとかでエントリを表形式で一覧表示し、カテゴリでソートしたい時(というかデスクトップ型のRSSリーダーは皆そういう機能を持っていると思います)、一エントリに複数のカテゴリが並列で並んでいると、どれを取ってソートすべきか分からないからです。Bloglinesでも意図したとおりにならない事を確認してます。

Atomフォーマットでなんらかの方法で主カテゴリを指定する方法(拡張で例えばisPrimary属性)をとるか、一番上(または最後)のを主カテゴリとする事に決めるかしないとまずいと思います。どちらにしても現在のMTのテンプレート標準機能では実現できなそうな感じです。(「Compareプラグイン」でMTIfEqual使うとかありますが...)

問題はありながらも、「Atom1.0 MovableType テンプレート(案)」の方ではとりあえず複数カテゴリ並べるようにしました。というのも、Atomフォーマットはブログ記事等のアーカイブにも使われます。例えば、Atomフォーマットで全ブログ記事をBlogWriteに取り込んで(実装予定)...といった用いられ方があります。となると、カテゴリ情報が欠落、という事態になるとこれはこれで問題となると思ったからです。

フィードバック歓迎です。

投稿者 BlogWrite担当 : 07:19 | コメント (0) | トラックバック

2005年07月22日

Atomでポッドキャストの実際

Atomでもポッドキャスティングを、という事で「IT Conversations」のポッドキャストフィードをAtom1.0に変換してみたとか。

Atom1.0では、RSS2.0と異なり(?)、一つのエントリに複数のファイル(RSSで言う enclosure)を配信する事が出来ます。という事はITConversationsがBitTorrentに対応すれば(現在作業中らしい)、BitTorrentファイルも同時に配信とかする事が出来るそうです。 AACとMP3の異なる音声ファイルフォーマットを同時に配信したい場合などにも便利ですね。

具体的サンプルは、続く

投稿者 BlogWrite担当 : 19:10 | コメント (0) | トラックバック

2005年07月20日

Livedoor Blog AtomAPIのエンドポイント変更

サポートフォーラムやメール等で、Livedoor Blogでの問題に関するお問い合わせが増えてきて、どうもLivedoorのシステム移行により、新環境で新たに取得したアカウントでのみ問題が起きているという事が分かってきました。

そんな中、「 新環境のエントリーポイントがやっと公開されたので、BlogWriteで投稿してみるテスト」(<-感謝)というエントリーを見かけ、え?新環境のエントリーポイントってなんだ...? と焦って調べたら、先ほど開発日誌で告知されたようです。

 ■Atom APIの変更
Atom APIのURLがリニューアルに伴い変更となります。
http://cms.blog.livedoor.com/atom

アップデート:BlogWrite2.2.2.8に更新しました。

移行後のシステムで取得した新しいアカウントでは、BlogWriteでの新規アカウント追加時、「新Livedoor Blog」を選択してください。旧環境で取得したLivedoor Blogのアカウントでは「旧Livedoor Blog」を選択するようにしてください。

すでにBlogWriteに登録してあるLivedoor Blogのアカウントで新環境に移行した場合、BlogWriteの「アカウントの設定」で「エンドポイント」を
http://blog.livedoor.com/atom
から
http://cms.blog.livedoor.com/atom
へ変更していたくようお願いいたします。

追記:観測気球さんのブログにもあがってました

投稿者 BlogWrite担当 : 01:04 | コメント (1) | トラックバック

2005年07月19日

MSN Spacesのブログ投稿APIは...

以前も触れた、マイクロソフトのブログサービス、MSNスペースでのブログ投稿APIは結局、「Blogger/MetaWeblog API over HTTPS/SSL」になりそうだと開発チームのDareさんがブログで書いています。それも近い将来に公開されるであろうと。

Update on Blog Posting APIs and MSN Spaces.

幾つかのクライアントソフトを上げて既存のクライアントソフトのユーザーにソフトの乗換えを強いないように、と広い互換性を重要視しているあたり、無難な選択肢を選んだようです。AtomAPIは現時点ではまだ策定中ですし、まだAtomAPIに対応していないクライアントでも使える、という理由がありそうです。

XML-RPCは、Atomと違って名前空間を使った拡張ができないので、変な変更や独自メソッドや引数作られると厄介この上ないです。かち合ったり重複したりすることもありますし

今回、彼(Dareさん)がそこまで気を使っているという事ですから、大きな変更なしでBlogWriteからもMSNスペースへ投稿出来るようになると考えても良さそうです、多分。

追記:
面白いのは、Bloggerの開発者(つまりはGoogleの中の人)でおなじみのJasonさんが、「ども、ありがと。でもね、ウチのBloggerAPIかなり古くてさ、実はもっと機能的なAtomAPIを開発者の皆にお勧めしてるんだ...参考になればいいんだけど」なんてコメントを残しているあたり。アメリカはこういう所オープンで良いですね。

投稿者 BlogWrite担当 : 12:28 | コメント (0) | トラックバック

2005年07月18日

Atom1.0 MovableType テンプレート(案)

MovableTypeでAtom1.0を配信するためのMTテンプレートを作ってみました。基本的にはValidなんですが、細かい点で、間違いや改良点等あるかもしれません。ご指摘いただくと嬉しいです…。

追記:
atom:idにurn:uuidを使いたいのだけれど、MovableTypeのテンプレートタグに該当するタグがないと思われ。なるべくUUIDを使うのが好ましいので何とかしたいところ...。 はたまた、従来通りtag : URI(*1)を使うべきか...。 追記:TagURIを使うように変更しました。

このプログでのサンプルAtom1.0フィード

投稿者 BlogWrite担当 : 08:52 | コメント (0) | トラックバック

2005年07月17日

RSS 2.0 と Atom 1.0 の比較

RSS 2.0 と Atom 1.0 の比較

Bray氏のサイトのページ「RSS 2.0 and Atom 1.0, Compared」を翻訳したものです。著作権は氏に帰属してないかも…(Atom公式Wikiの要約なので…後でメールで確認します)。問題があれば連絡ください。 

投稿者 BlogWrite担当 : 00:12 | コメント (0) | トラックバック

2005年07月16日

Atom1.0配信フォーマット、実質的に完成

形式的には、IETFでの作業はまだ残っている所ですが、Atomフォーマット1.0は実質完成したといっても良いのではないでしょうか。と、Tim Bray氏も言っているし

The Atom Syndication Format - draft-ietf-atompub-format-10
さらに読みやすい版はこちら

RSSリーダ的に言うと、今から対応考えないといけない頃かと思います。BlogWrite(のようなクライアント)的には、AtomAPI(AtomPP)が完成するまでは考える必要はないかと思っています。

実は先月、某Webサービス系ムック本のためにRSS・Atom記事をまた書きました。微妙に間に合わなかった感じ。それにAtomAPIの章と整合性が取れなくなってしまうという事もあってベースは現行使われているAtomAPIを元にしています。はてなやアマゾンなどのWebサービスも一緒に載るそうですので楽しみなんですが、いつ出るのかは不明です。

なんか、Atom1.0の新機能や仕様を解説せよ、というプレッシャーを微妙に感じるのですが^^; すべてを解説するのはなかなか大変。基本はここで書いたので、ほとんど十分だと思います。あとは細かい個々の点なので、必要に応じて仕様を...。といいたい所ですが、RSSで起きたような混乱を招かないためにも(Atomは仕様自体がしっかりしているので解釈の混乱は起きにくいですが)、今のうちにしっかりした解説が必要なのかとも思ったりしています。

投稿者 BlogWrite担当 : 12:11 | コメント (0) | トラックバック

2005年07月13日

So-net blogのAtomAPI:UploadURI

以前も書きましたが、So-net blog AtomAPI仕様での画像等のアップロードに関して、UploadURIを取得できるとあります。しかし、UploadURIに関してはそれ以降何も言及がなく、利用方法が分かりません。しかし、So-netさんのAtomAPIの仕様を見ている限り、TypePadやMovableTypeで使われているPerlのライブラリ、XML::Atomを使っているような気がします。(<-単に気がするだけです) という事は、TypePadやMovableTypeでのUploadURIと同様の挙動をするのではないか、と思います。

しかし、So-net blogには画像投稿用の「imageサービス」も用意されています。恐らく、エンドポイントが異なる「imageサービス」というのは、SixApartの名前空間を省いた、TypePadの「Photo Albums」に相当するものか、と思います。この別エンドポイントの「imageサービス」を用いる利点としては、投稿した画像の一覧と削除が出来るということでしょう。

ではいったいどちらを実装すればよいのか...。

最新のAtomAPIの仕様を考慮に入れると、UploadURIを利用する方が投稿クライアントの設計上好ましいです。単にUploadURIをCollectionの一つとして扱うようにすれば良いからです。Collectionを利用すれば、一覧も削除も出来ますので、別エンドポイントにする必要性も利便性もありません。現在少なくともMTとTypePadがUploadURIに対応しているはずです(が、日本語周りの不具合でいずれも動かない)。LivedoorとBloggerは未対応。

「imageサービス」を利用するとすれば、BlogWriteのAtomAPI実装に(UIも含めて)大幅な変更が必要な上、対応しているのは、So-net blogだけです。

悩ましい。 一番良いのは早いところ、AtomAPIの仕様が正式に決定する事なんですが...。

投稿者 BlogWrite担当 : 12:53 | コメント (0) | トラックバック

AtomAPIとCollection

Atomフォーマットは、完成まで一週間を切ったとかいう感じですが、AtomAPI(正確には、The Atom Publishing Protocolで、日本ではAtomPPとも、海外では「APP」とも略される)の最新動向はというと、完成まで、雑感ではおそらく今年いっぱいかかると思われます。

現状のEditURIとかPostURIとかCategoryURI、UploadURI、ResourceURIとかはばっさり捨てられています。基本的な流れは変わっていませんが、用語とか、フォーマット、拡張性が根本から変更されたと言っても構わないでしょう。

続き

AtomAPIに新規に導入された機能・概念

workspaces
Workspaceというのが、例えばブログだったり、Wikiだったりしますが、ブログのみに用いられるわけではないので、特に似たようなのであれば何でも構いません。

<?xml version="1.0" encoding='utf-8'?>
<service xmlns="http://purl.org/atom/app#">
     <workspace title="My Blog" > 
        <collection contents="entries" title="Blog Entries" 
            href="http://example/atom/myblog/entries" />
        <collection contents="generic" title="File Uploads" 
            href="http://example/atom/myblog/generic" />
     </workspace>
</service>

collections
Workspaceに含まれるのがCollectionです。Collectionとは、具体的にはブログで言うところの、エントリー(記事)、カテゴリー、ファイル、画像、動画、リンク、雛形、等々の一覧です。

Collectionに関連付けられたURIにGETすると、その一覧、つまりCollectionを取得できます。

<?xml version="1.0" encoding='utf-8'?>
<collection xmlns="http://purl.org/atom/app#">
   <member title="ほげ?フガフガ"
         href="http://example.com/atom/myblog/entry/7700a0" 
         updated="2005-07-16T23:09:03-0500" />
   <member title="フガフグ"
         href="http://example.com/atom/myblog/entry/7700c9" 
         updated="2005-07-15T23:06:09-0550" />
</collection>  

memberが個々のアイテムといって良いでしょう。このCollectionのURIにPOSTするとmemberの新規追加で、以前(PostURI相当)と同様の挙動ですね。memberに関連付けられたURI(EditURI相当)にGETすれば、アイテムがEntryドキュメントとして返ってきます。PUTすると更新、DELETEすると削除。

リソースのアップロードで異なるのは、現状ではEntryドキュメントにBase64で埋め込んでいましたが、バイナリーChunkをそのままアップロードします。
   POST /collection HTTP/1.1
   Host: example.com
   Accept: application/atomcoll+xml
   Content-Type: image/png
   Content-Length: nnnn
   Name: hoge.png

   ...binary data...

Rangeヘッダー
member(ブログでいう記事)の取得において、範囲を指定する方法が既定されました。これは、HTTP1.1のRangeヘッダーを利用して日付で指定できます。

ここらあたりまで決まったのが、draft-ietf-atompub-protocol-04.txtです。

現状の問題点として、collectionの種類が、「entries」と「generic」しかないため、collectionが複数あった場合、BlogWriteのようなクライアントソフトは記事や画像その他の投稿先をどのように判断するのか...という点があります。というのも、もし画像とカテゴリのCollectionがgenericとして二つあった場合、ソフトウェア的にどっちがどっちだと判断できないからです。かといってカチッと決めてしまうと汎用性を損なう恐れがありますから、議論の余地があります。

その、Collectionsの識別を議論しているのが、MLの「Which collections to upload and post to」から始まるスレッドです。これがはっきりするまで、実装するのはまだ早いかとな思います。

投稿者 BlogWrite担当 : 09:18 | コメント (0) | トラックバック

2005年07月10日

RSSなんて通じない

今年の夏にでもIEの最新版が公開され、RSS・Atomの登録が一般の方でも簡単になるという時期を向かえ、XMLコンテンツフィード(笑)とシンディケーション(爆)の普及は次なるフェースへ突入すると思われます。

というのも、新IE7には、FireFoxやSafariと同様に、閲覧中のページからRSS・Atomへのリンクを見つけて「お気に入り」と同じ感覚で登録出来るようになるからです。(ただし、一部で言われているような、IE=一般的なRSSリーダと同等の機能、という訳では無い) 具体的にはIE7では、RSS・Atomを見つけるとボタンが光って、ユーザはそれをクリックするだけで登録出来るようになるわけです。また、直接RSS・Atomの内容をプレビューする機能もつく(現在だと生XMLが表示される事も多い)といいます。

これで「 所望のRSSフィードをRSSリーダーに登録させるのはまだまだ敷居が高い」と言われる問題は解決します。(もし「お気に入りを登録をさせるのも敷居が高い」というのでしたらまた別ですが)

そこで問題となるのは、このまま、RSS、Atom、XML、Feedなんて名称でよいのか、という事です。現にFireFoxでは「LiveBookmark」と表現されて英語圏の人にとっては普通の人でも分かりやすい、また機能を連想しやすいものとなっています。

本当に一般化するためには、何らかの名称がないと、話題にする時も通じないのではと思うのです。「ほら、ブラウザで見つかると光って、ボタンを押すと登録されて更新があると、更新内容を教えてくれる、アレだよ」..なんて言っていたら話す方も疲れます。もちろんRSSなんていっても普通は通じません。 名前というのは意外と大事なんですよね。

MicrosoftがBookmarkを「お気に入り」との表現(個人的にはスキクナイ)で利用して一般に定着したように、今度のIE7ではどう出てくるか楽しみだったりします。

Inspired by 消費者に向かって,技術用語“RSS”を使わないように
関連記事:MSの次世代OS LonghornでのRSSサポート

投稿者 BlogWrite担当 : 16:51 | コメント (0) | トラックバック

2005年07月06日

So-net blogがAtomAPI採用

AtomAPI機能追加 - 開発チームのブログ

So-net blog AtomAPI仕様

素晴らしい

So-netさんでのAtomAPI実装では今までの他のAtomAPI実装より一歩進んで、高機能な実装になっています。

記事のページ送り
記事の投稿、削除、変更、最近の記事取得に加え、ページ送りによる古い記事の取得もサポートしている。

画像の投稿、削除、一覧取得(ページ送りで古いのも取得)
他のAtomAPI実装ではサポートしていなかった(TypePadでのGalleryはちょっと別として)AtomAPIによる画像の投稿、削除、一覧をサポートしている。

まだテストしていないので、実際のところの動作がどうかは分かりませんが、「BlogWriteひとまず動いている」とのブログエントリも見かけます。

既存のAtomAPI実装(LivedoorBlog、Blogger)での問題が、
・自動改行を管理画面でオフにしないといけない
So-netBlogではどうなっているか気になりますが、おそらく大丈夫でしょう。

また、IETFにおけるAtomAPIの最終仕様は今年末になるとも言われているので、時期としても今AtomAPI対応やっちゃうってのもありなんじゃないでしょか。半年あるんだし…。

問題は、画像の追加がまたなんというか、まだ一般に決まっていない方法なので、BlogWriteで実装するか悩むところですが、他でやってないんだし必要性が十分あるものなので、検討したいと思っています。でも本音は各ブログ共通の方法が出来上がるまでやりたくないな...という所ですし、実際BlogWriteで対応しようにも、So-net会員でなくてもアカウント取れるのでしょうか...。

追記:
仕様書には、 「記事用AtomAPIのルートエンドポイントに対するGETでUploadURI が取得できる」とあるのですが、UploadURIに関する言及はそれだけで、UploadURIがどのようなデータを期待するのかが不明です。ResourcePostURIと同種のものでしょうか。これが、もしその名前が示唆するような、ファイル等のアップロードのためであれば、このURLに画像をアップロードすれば、別に、画像専用のルートエンドポイントのImageサービス?を使う必要はないのではないかと思うのですが、どうなんでしょか。投稿アプリケーションの設計としては、こちらの方がキレイなんですが...。


追追記:
UploadURIについては、私が自分で書いてました^^;。

とりあえず、実際にテストは出来ないながらも、このUploadURIの方を使った画像のアップロードには対応しようと思います。出来ればLivedoorとかもファイルアップロード対応して欲しいな...

追追追記:
AtomAPIを使ってみた
で、So-net blogでのBlogWriteの動作レポートいただきました。 感謝

投稿者 BlogWrite担当 : 23:05 | コメント (3) | トラックバック

2005年06月23日

最新のAtom フォーマット ID-09と...(updated)

本日(といってもあちらの時間ではまだですが23日のことです)、IESG(The Internet Engineering Steering Group)のミーティングにて、Atomフォーマットの正式なレビュー結果が明らかになります。結果によって変更が必要となるか、IETF( Internet Engineering Task Force )のRFCとしての公開へ向けて最後のドラフト公開へと進むか、という段階です。

Update:どうもIESG委員の一人が延期の申し立てをしたらしく、あと2週間ばかり待たなければならなくなった模様です。残念。特に問題があったからというわけではなく、おそらく単にレビューする時間が取れなかったからゴメン延期、と言う感じみたいです。

最新のAtomフォーマットのドラフトは:
http://www.ietf.org/internet-drafts/draft-ietf-atompub-format-09.txt

参考リンク:
IETFとは
  IETFにおける標準化プロセス

AtomはTCP/IPなんかと同じ、RFCになっちゃんだと、感慨深げ...。というほどでもないけれど、とにもかくにも早く作業がすすんでほしいものです。

追記:Atom APIの方はまだのようですね。

投稿者 BlogWrite担当 : 14:29 | コメント (0) | トラックバック

2005年06月11日

XML-Atom

XML-Atom 0.12 - blog.bulknews.net
CPANに登録されている、AtomフォーマットやAPI用のPerlモジュールのXML-Atom。マルチバイト関連のバグが解消され、オリジナル作者(MTの人)から引き継いだmiyagawaさんがメンテする、とのことです。

TypePadやMovableType(あとLivedoor Blogも?)でのAtomAPI利用とかで、色々改善されるんじゃないかと思いつつ、XML-Atomモジュールに関するより多くの文書・サンプルとか色々期待しちゃいますね。

一つ現実的な要望なのですが、レンタルサーバーとかにもインストールできるように、XML::LibXMLやMIME::Base64 をはずしてファイルコピーでインストールできるPurePerl版のXML-Atomって出来ないんでしょうか。

AtomAPIを利用して、ちょっとしたサイト連携サービスを行いたい時、XML::Atomを使いたいと良く思うのですが、管理者権限のないPerl5.6とかのレンタルサーバーでは簡単に設置できないため不便に思っています。かと言って一からAtomAPIサーバーを作るのもひどく効率が悪く...。きっとこういった需要もあるのではないかと思いますが...って自分が使いたいとも言う...。

投稿者 BlogWrite担当 : 04:04 | コメント (0) | トラックバック

2005年05月29日

Blogger AtomAPIを拡張しDraft投稿できるように

BloggerのMLからの情報ですが、BloggerのAtomAPI経由の投稿で、下書き投稿が出来るようにAtomAPIを拡張する予定だそうです。

具体的には、

<entry>
 <title>stuff</title>
 <content>stuff</content>
 <issued>timestamp</issued>
 <blogger:draft>true</blogger:draft>
</entry>

bloggerの名前空間(http://www.blogger.com/atom/ns#)で、draftタグを追加し、値がtrueであれば下書きになるそうです。

BlogWriteIIでは下書きの管理をローカルで行えるので、必要なさげですが、自宅でBlogWriteからいったん下書き投稿し、出先のPCで仕上て投稿&公開というケースもありそうなので、Bloggerで実装されたらこの拡張にも対応してみます。

問題は他のAtomAPIを使うサービス(LivedoorBlog等)でこの拡張に対応してるかどうか、投稿時にどう判断するか...という事。あまり素のサービス固有機能は使いたくないというのが本音です。ただでさえXML-RPCかAtomAPI(かつ認証がWSSEかSSL)かという処理があるのに、さらにBloggerかLivedoorかTypePadかMovableTypeかそれともHogeHogeか、なんて処理をソースのあちらこちらにハードコーディングで入れ始めたらいずれ破綻してしまいます。

どうせなら、Draftだけでなく自動改行の指定やコメント可・不可の指定等含めて、共通のAtomAPI Weblog拡張モジュールみたいにワンセットがあれば良いのだけど...。

投稿者 BlogWrite担当 : 06:19 | コメント (2) | トラックバック

2005年05月12日

The Atom Publishing Protocol - draft4

draft-ietf-atompub-protocol-04, (HTML形式等のフォーマットではこちらが読みやすい)

ぱっと見、Atom Entry Document関連の記述がごっそりなくなり(おそらくAtomフォーマットと切り離し、バージョンが変わった時等の仕様の整合性を保つ為か)サッパリし、主にコレクション関連の記述が目立ちます。

逆にいうと、この仕様だけ見たら全容はまったく良く分からないという事だったりします。さらに、個人的にはエラー時のHTTPステータスコードの規定、標準的なエラー説明文の形式、などなどまだまだ曖昧です。

欲を言うと、もっとサンプルが欲しいですね..。でもAtom界隈には、なぜか優秀なプロのモノ書きが沢山いる(Mark Pilgrim, Danny Ayers, Joe Gregorioなどなど)ので、いずれ解説がガンガン出てくると思いますが。

ユーザーから見た具体的な利点とすれば、コレクションの導入により、投稿した画像の一覧、記事の一覧等を日時の範囲を指定して取得できるという事でしょうか。現状では、XML-PRCも含めて、画像の一覧が取れない、というのは物足りなくなって来ています。さらに、実装によってはカテゴリの一覧取得だけでなく、カテゴリの新規作成も可能かと思います。ブログの新規作成も可能かどうか...はまだ不明ですが...。

投稿者 BlogWrite担当 : 13:54 | コメント (0) | トラックバック

2005年05月06日

Atom Implementation Guide

Atom関連ツール開発者向けの文書、Atom Implementation Guideを発見。まだ、TODOになっている項目が多いけれど、今後Atom関連のツールを開発して行く上で指針となりそうな文書です。

投稿者 BlogWrite担当 : 22:08 | コメント (0) | トラックバック

2005年04月07日

はてなブックマーク AtomAPI

が出たそうです。
はてなブックマークAtomAPI

用途としては、FireFoxのExtentionでツールバーから1Clickではてなブックマークに追加したり、ブログのサイドバーに「最近のブックマーク」みたいにして埋め込んだり、ローカルのお気に入りとはてなブックマークとの同期を取ったり...と妄想が広がります。

さて、このオープンなAPIを利用したどんなアプリケーションが出てくるのでしょうか。

個人的には、MTのIndex再構築時に「最近のブックマーク」をサイドバーに挿入させたいので、誰かPlugin作ってください。M(_'_)M


あ、はてなダイアリーのAtomAPIも期待しております。

投稿者 BlogWrite担当 : 19:33 | コメント (1) | トラックバック

2005年04月02日

P2P Feed clientに関する考察

DecentralizedなP2P のネットワーク上にRSSやAtomその他の情報が流れ、クライアントは"Subscribe"しているRSS・Atomによる情報をリアルタイムに閲覧する。

P2Pを利用したリアルタイムRSS・Atomクライアント。

既存の概念や技術を揺るがすような、ソフトウェア技術のパラダイムシフトは従来から多くが個人やISVによってなされてきた。特にP2Pに代表される技術においては全米を席巻したNapsterから始り、Kazaa、Gnutella、Freenet、Winny、Groksterと様々なソフトウェアが大学生や個人により開発され、最近ではSkypeに代表される音声通話の実現に多大な貢献をしている。

P2Pネットワークにおいては、central serverを介するP2Pと、decentralizedされたPure P2Pとがある。過去の例から学ぶのであれば、大規模な汎用的P2Pネットワークを構成する要件に適するのは、後者のPure P2Pの技術である。前者のP2Pネットワーク型は管理と開発の容易さから既にIM(インスタントメッセージ)等で広く使われてきた所であるが、その設計上の理由故に、中央サーバーの管理の問題とネットワークの権利の問題が発生する。例えば、MSN、またはYahoo!のIMをシャットダウンするのは、MicrosoftまたはYahoo!の胸一存である(*1)。

ここでは、このPure P2Pネットワークを利用した情報の流通を少し考えてみる。現在のRSS・Atomリーダーは古くからのHTTPのGETリクエストをそれぞれのFeedに対し行ない、RSS・Atom形式の"ファイル"を"ダウンロード"してきた。P2Pのネットワークにおいては、"データ"は"ストリーム"として流れてくる。

現在のRSS・Atom流通に当てはめて考えると、ここで幾つか疑問が湧いてくる。


  1. RSS・Atomによる情報はどのようにしてネットワークに公開されるのか。

  2. クライアントはどのように求めるFeedを"Subscribe"するのか。

現在すでに、テクノラティやBloglines、FeedBack、Bulkfeedsといった大規模なRSS・Atomアグリゲーションサーバーが存在している。今の用途は主にキーワードによる検索だが、Update Pingによる通知や独自にアグリゲートして集められたRSS・Atomを逐次このP2Pネットワークに配信していく(*2)。それと同時に個別にこのP2PネットワークにJoinして配信する事も可能にする。

クライアントは今の方法と同じく、サイト上におかれたRSS・XML・Atomを登録し、そのURI及びFeedに関連付けられたIDを取得する。このID及びURIによる識別を利用しP2Pネットワークにより流れてくるデータから登録されたFeedのデータのみ取得する。

RSS・Atom配信者にとっては、既存の確立された方式を一切変更する事なく、中間のディストリビューション層のみ、P2Pにより置き換えることにより、全体として移行が容易、かつスケーラビリティ、スピードが劇的に改善される。

結果的にP2Pの利点である双方向性も活かし自ら情報をP2Pネットワークに配信する事も可能となる。

さらに、RSSやAtom形式のデータだけでなく、同じような他のXMLで標準化されたデータも流通させることにより、様々な"特定"用途に用いる事が可能となる。WWWから独立した新たなプラットフォームとなる可能性も秘めている(*3)。

この方式の欠点は、ソフトウェアを開発する上で、開発者だけでなくユーザも古くから馴染んできた枯れたHTTPという技術ではなく、普段使わないより高度な技術を採用しなければならない、という事にある。そのため、P2Pを利用したソフトウェアの開発は現状ではコストがかかる。HTTPの利用であれば、開発者は様々なツールやコンポーネントを利用し開発を行なう事も出来た。しかし新しい技術ではそれらの資産を利用する事は出来ず、P2Pのネットワークに関わる開発ではTCP・IPレベルの知識が要求されるだろう。しかしながら、より多く使われるほどより使われる技術はカプセル化、コンポーネント化され、開発者の負担も軽減するのは(インターネットの歴史を見ても)明らかである。

では、今P2Pによるネットワークに移行すべきなのか。これは重要な質問である。ここで提示しているモデルでは、どちらか一方の方法を選択しなければならないのではなく、クライアントはP2P経由でも情報を取得できるだけでなく、HTTP経由のGETでいままで通り直接取得することでも同じ結果が得られる、という前提は一応確認しておく。ただ、曲がりなりにも既存のHTTP GETで出来てしまう事をなぜわざわざP2Pで行なわなければならないのか、という疑問に対する決定的な答えが出ない限り、P2Pによる流通へは移行しないかもしれない。しかしながら、いつ「その時」が来るか分からないのが、このインターネットの世界の醍醐味でもある。


(*1)JabberというXMLベースのオープンなプロトコルがあるが、Pure P2Pでは無い。
(*2)この方式によるビジネスモデルとしては未知数だが、現在の負荷増大に対処するためのコストは、P2Pネットワークの利用により激減するはず。
(*3)ただし、現状ではコンテンツ流通のプラットフォームとしてではなく、コンテンツに関するメタデータの流通を目指す方が各方面の抵抗が少ないだろう。

エラそうな文体で書いてますが眠くてぶっ倒れそうな時に勢いで書いただけなので、テキトーです。

投稿者 BlogWrite担当 : 11:57 | コメント (0) | トラックバック

2005年04月01日

「Developing Feeds with RSS and Atom」

Ben Hammersley氏による、「Developing Feeds with RSS and Atom」が洋書で近日発売予定として予約可能になったので早速予約しました。オライリーから待望のRSS・Atom本です。

著者は、「Content Syndication With RSS」としてすでにRSS本を出していますが、今回はAtomにかなりのページを割いて、すべて一から書き直した、まったく新しい本となっているそうです。「Content Syndication...」の方をチラッと読んだ限りで判断すると、今回の「Developing Feeds with...」はRSSやAtomを使ったXMLシンジケーションに関する本としての決定打となるのではと思います。

もっとも、AtomがIETFで正式なものとなるのは今月中のはずなので、内容がどれだけ新しい仕様に則しているか、またAtomAPIについてどれだけカバーしているのか詳細は不明です...。

でもなんだかんだ言って、手にとるのがとても楽しみだったりしています。今回は翻訳本は出るのでしょうか...。

解説:Atom

追記:
Beginning RSS And Atom Programming」も予約可になっていました。
著者の一人である、Danny Ayers氏はAtomのメーリングリストでも活発に活動しています。Atomの技術的詳細をディープに掘り下げて知るにはこちらが適しているかもしれません。

さらに調べたら、「Hacking RSS and Atom」なんてのもありました。こちらは知らなかった...。オライリーのHack本ではないようだけれど、内容は面白そう。

  • Routing RSS feeds to your email inbox
  • Integrating RSS feeds into Instant messaging systems including AOL
  • Taking your RSS feeds with you – on your Palm device, or even an iPod!
  • Combining RSS and BitTorrent
  • Creating Podcasts, and building your own podcast aggregator
  • Creating your own feeds from scratch

追追記:
あれ!日本のアマゾンだと、「Hacking RSS」になってる...。"Atom"を省くなんて犯罪だ!w


今年の春はまさにRSS・Atom本の出版ラッシュですね。どの本もAtomやPodCasting関連など最新のトレンドを前面にもってくるのではないでしょうか。

投稿者 BlogWrite担当 : 01:13 | コメント (0) | トラックバック

2005年03月25日

テクノラティの日本サイトがオープン

テクノラティの日本サイトがオープンしました。去年から首を長くして待っていました。まだα版のようです。

ブログ界隈のほぼリアルタイム動向検索とでも言いましょうか...。RSSと連携していない(?)ので個人的には利用頻度は高くないですが...。色々と便利に使えそうです。

さらには、
こんな風に、自分のサイトにリンクしてくれている記事を見つけるコトも出来ます。

RSS・Atom・XML-RPC Pingによる通知に、検索エンジンを融合させるという、新正統派的(?笑)検索エンジンというだけでなく、他にも面白い機能やAPIを用意(少なくとも本家では)しています。日本サイトにも期待しています。(HepCatのようなRSSリーダとの連携も含めて)

こういったものを活用して何が良いのか、と聞かれる方に対する返答は、カスタマーが求めているものをより早く、より的確に収集することが出来るからだ、と答えています。

日本では以前から、BulkfeedsやFeedBack、ライブドア未来検索といった有名なRSS検索サービスがあり便利に使えます。

投稿者 BlogWrite担当 : 20:07 | コメント (0) | トラックバック

2005年03月24日

Atom Protocol03最新ドラフト


Atom Publishing Protocolドラフト最新03版が公開

The Atom Publishing Protocol

Collection
Introspection
関連がとても良い感じで、前よりだいぶ良くなりましたね...。
実装しなければならない仕様が微妙に増えたけれど、機能が増えたわけなので良いと思います。

投稿者 BlogWrite担当 : 14:12 | コメント (0) | トラックバック

2005年03月17日

Atom Internet-Draft 06

IETFからだされたAtom Formatの最新Internet-Draft。
http://www.ietf.org/internet-drafts/draft-ietf-atompub-format-06.txt

ドラフト版の06なんですが、今回結構変わってます。

Head要素がまた無くなった。
ID要素がIRIとかいうアイルランドの酔っ払いのような名前になったとか(というか、urn:uuidって何よ、みたいな)

HTML版
http://atompub.org/2005/03/12/draft-ietf-atompub-format-06.html
テキスト版
http://ietf.org/internet-drafts/draft-ietf-atompub-format-06.txt
前バージョンからのDiff
http://atompub.org/2005/03/12/draft-ietf-atompub-format-06-from-5.diff.html

追記:

Head要素については、

feed->title
feed->entry->title
の方が確かに直感的。「feedのプロパティであるtitle」「entryのプロパティであるtitle」見たいな..。
↓のような事も言えるし。
http://inessential.com/?comments=1&postid=2992
by MarsEditやNetNewsWireの開発者の方。

しかしながら、一般的には、
feed->head->title
の方が処理する上で都合が良い、のは確か...。

投稿者 BlogWrite担当 : 18:23 | コメント (0) | トラックバック

2005年03月12日

Blogger AtomAPI 認証方式がWSSEからBasic Authへ

BloggerのAtomAPIの認証方法に変更があったようなので、BlogWriteからBlogger.comのブログにログイン出来ない場合があります。
Authorization: Status on SSL/Auth Basic?

認証方法が、WSSEからBasic Authになったようです。が...SSL通信はまだのようなので、ほにゃにゃらエンコード(笑)したユーザー名とパスが普通のHTTPで送信されてしまいます。まったくの平文のXML-RPCよりはマシというぐらいです。Blogger.comの意図がちょっと見えません...。

という事で、
BlogWriteアップデートVer.1.4.0です。


追記:
SSL通信が有効になったそうです。
エンドポイントも、
https://www.blogger.com/atom
に変更出来ます。
一、二週間したら、すべての
http://www.blogger.com/atom
へのリクエストは、https://...のSSLの方にリダイレクトされるそうです。


追追記:
Bloggerから「Blogger AtomAPI Documentation」公開
http://code.blogspot.com/archives/atom-docs.html

投稿者 BlogWrite担当 : 01:05 | コメント (0) | トラックバック

2005年03月03日

解説:Atom

技術評論社の編集者の方より寛大なる許可を得て、技術評論社「Software Design」2005年1月号 第2特集「次世代Webテクノロジ:Atom基礎講座」オンライン版を公開したいと思います。

解説:Atom - Atomとは何か: RSSやXML-RPCとの比較、そしてAtomAPIの使い方まで

どぞ。

#草稿を元にXHTMLを生成したので、タイポやバグってる所があるかと思います。おいおい修正いたします。なお、執筆は2004年の10月頃のため、一部情報が古くなっている個所がありますがご容赦ください。これもおいおい余力が出たら更新いたします。
もし、記事に間違い、勘違い、誤解ありましたらぜひツッコミ頂きたく思います。m(_'_)m

投稿者 BlogWrite担当 : 17:42 | コメント (0) | トラックバック

2005年03月01日

AtomAPI Photo UploaderをC#Builderでコンパイル

何はなくとも XML InfoSet: 続 AtomAPIPhotoUploader
はてなフォトライフアップローダー

AtomAPIを使った写真のアップロードクライアント。

ブログは前からHepCatで購読してました。あのアマゾンの吉松さんだとは知らずに^^; blog.bulknews.net: AtomAPI Photo Uploader

ちょっとタイミングが遅れましたが、ダウンロードしてみました。ソースの方を。
手持ちのC#Builderでコンパイル問題なく通りました。プロジェクトファイル作って二行ほど変更するだけでした。

BorlandのC#Builderは無料でダウンロード出来るはずなので、みんなでウリャーと開発出来るのではないかと思ったり。それだけ興味がある人が居るのかどうか不明ですが...。(私?はBlogWrite&HepCatで手一杯だったり...)

ただし、ライセンスの方が記載されていないので、それがはっきりすれば開発に参加しやすいのではと思います。クリエイティブ・コモンズとかにして、SourceForgeとかに登録してCVS使えば便利ですしね。

投稿者 BlogWrite担当 : 16:10 | コメント (0) | トラックバック

2005年02月28日

不動産情報とXML

今日はちょっとお呼ばれして某大手不動産情報サイトさんの会社に行ってきました。
私ドモが一年以上前から業界に提案していた、不動産の物件情報のXMLによる標準化という動きが少し実現の方向へ向かいそうであります。

個人的には、BlogWriteでも使っている(技術評論社のAtomAPI記事にも書いた)Atom Publishing Protocolに不動産情報をのせてやり取りすればいいじゃんと思ってたりします。ハイ。

儲かりもしない事ですが、喜んで参加するつもりではおります。

不動産情報の流通という事で、現状の問題点:

■一般の不動産会社にとって各種情報サイトに物件情報を登録するのはかなりの負担。
結果として:
 ◇古い情報が残ったまま
 ◇タイムリーに情報が届かない
 ◇そもそも登録しないー>客が来ない

つまり、「一々サイト毎に一つ一つ物件情報を入力して、一々チェックしてられねーよ」という事であります。
でも、それでは客としても不便ですし、不動産業者も困る。

解決策:
  • 不動産物件の管理ソフトウェアのデータを情報サイトのデータを連携させればいーじゃんBlogWriteでやってるみたいに

よってXML(それ以外のフォーマットは考えられない)によりデータフォーマットを決定し、誰でも使えるように各種不動産物件管理ソフト等と各種不動産情報サイト等での共通の仕様として策定しようではないか。

という事だったりします。この仕組みはBlogWriteが記事を投稿、削除、更新するのとまったく同じ流れであり、項目は違えど、必要とされる機能は同じです。海外では1998年当時より不動産情報を扱う、XMLによる規格が既に存在していたりします。

また既に規格の仕様書として私の作成した(三日ででっち上げた)XMLスキーマとDTDの定義は済んでおり、後は使うだけなんですが、一人で使ってもしょうが無いですし、そもそもXMLは異種他社混合でのデータ連携に用いるものですから、皆で使わないと意味がありません。

そういった流れで、今回少し表立った動きが始まるのでは、と期待しております。

追記:XMLスキーマですが、某NTTホニャララとか某ホゲホゲで作ると数千万かかるとか....。何故にそんなにかかるのかとっても不明であります。

投稿者 BlogWrite担当 : 19:23 | コメント (1) | トラックバック

2005年01月24日

AtomAPI.com is FREE

atomapi.com is FREE
だそうです。

OpenDomain.Orgというところが提供していて、基本的な規約に同意すれば、ドメイン名を無料で使えるとの事...。

日本語のリソースが少ないため、AtomAPIの日本語メーリングリストか何か(Google Groupとか)作ろうかと思いましたが、私自身がAtomAPIを利用したアプリケーションを開発している関係上、もし私が管理運営すると、参加しにくいと感じる方もいらっしゃるのではないかと思います。ドメインも無料で使えるし。どなたかやりませんか?^^;

ええただ言ってみただけです。ハイ。

ちなみに、SoftwareDesignに寄稿したAtom記事の元原稿も、ある程度期日が過ぎ許可をいただいたらWeb上で公開するつもりです。

追記:rssatom.comなんかも無料ですねー。他にも、AtomBlog.Org、AtomXml.Com、AtomProject.Net、AtomBlog.Com、AtomWiki.Net...

投稿者 BlogWrite担当 : 20:39 | コメント (5) | トラックバック

2005年01月18日

BlogClient 1.0 - Java AtomAPI クライアントライブラリ

AtomAPIネタ連発気味ですが...
たった今入ったAtomのMLのメールによると、JavaによるAtomAPIの実験的なクライアント用のライブラリが公開されたそうです。ライブラリとしてAtomAPIのツールが公開されたのは初めてでしょうか...?
ちなみに、XML-RPC(MetaWeblogAPIとBloggerAPI)にも対応しているとか。

Java使いの方はこれを使って簡単にAtomAPIでアレやコレや出来るのではないでしょうか。

投稿者 BlogWrite担当 : 19:40 | コメント (2) | トラックバック

FotolifeのAtomAPI実装が発表

FotolifeのAtomAPIが発表されました!

某所でチラッとアルファギークと呼ばれる方(笑)が洩らしていましたが、早くもリリースということで、素晴らしい。

詳しくは上記リンク先を見ていただくとして、Fotolifeは、はてなの運営するオンライン写真ギャラリーで、今回AtomAPIが実装された事により、さまざまなクライアントソフト、例えば、デジカメの写真管理ソフトや画像管理ツールとの連携が考えられます。

実際、海外ではつい最近も、BloggerのAtomAPIを利用した、デジカメの写真管理ソフトが発売されています。 このPhotoLightningというソフトは、AtomAPIにより、Bloggerと連携し、簡単にBloggerでフォトブログを作成できるようになっています。他にも、Blogger(Google)が買収した、Picasaというクールな画像管理ソフトも非常にうまくBloggerとの連携がなされています。

日本でも、この機会に上記のソフトに負けないクールなソフトが出てくる事を期待しています。

詳細についてはまた後ほど...(BlogWriteからの投稿等も検討してみます)

追記:AtomAPIとは何ぞやという方は、本屋さんへGO。まだSoftwareDesignのAtom特集があるはずです。

追追記:
はてなダイアリーのAtom対応については順次開発予定」だそうです!!!
す、す、素晴らしい!

追追追記:2005/03/05
Atom特集記事オンライン公開しました。
解説 Atom - Atomとは何か: RSSやXML-RPCとの比較、AtomAPIの使い方まで

投稿者 BlogWrite担当 : 18:01 | コメント (0) | トラックバック

BlogWriteが使えるブログ

突然ですが、BlogWriteが使える、ブログのサービスやツールって結局どれくらいあるのでしょうか...。

とりあえず、XML-RPC(BloggerAPI/MetaWeblogAPI/MovableTypeAPI)またはAtomAPIでの投稿に対応しているブログの種類は把握している限り、以下の通りなのですが、詳細が不明なのが以外に多いのです。

[サービス系]
TypePad
ココログ
ブログ人
livedoor Blog
OCN ラブログ
Blogger
News-Handler
Seesaa Blog
SweetBox Blog
NetLaputa Blog
269g(コメント参照)
LiveJournal?(未確認)

[ツール系]
MovableType
Wordpress
sb
Blosxom(BXRプラグインで対応)
Blojsom(可能だが詳細不明)
pplog2(可能だがエンドポイント不明)
Drupal(可能だが詳細不明)
Xoops(可能だが詳細不明)
COREBlog(可能だが詳細不明)
Nucleus(チト難あり)
tDiary(将来的に?)


今、BlogWriteのアカウント作成の所を組んでいて気になったので、「もっとあるぞ」とご存知の方がいらっしゃれば教えてください。確かLivedoor Blogはどこか他でも使われてるような気がするし、Seesaa Blogも結構色々な所で使われていそうです。
あと、可能なのは知っているのだけど、XML-RPCのエンドポイントが分からない等の詳細が不明なツールに、開発者の方やご存知の方に補足を入れていただければ嬉しいです。m(_'_)m

投稿者 BlogWrite担当 : 15:16 | コメント (7) | トラックバック

2004年12月21日

記事とかお礼とか

 暫く更新を怠っていたため、ついにトップページに表示される記事が無くなってしまっていました。肩の力を抜いてまた気楽に更新していきたいと思います。

 技術評論社さんから「Software Design」の一月号が発売され、Atomの特集記事が掲載されています。もし不明な点、間違い等ありましたら、ぜひお問い合わせいただければと思います。
 また、感想などいただけたら非常に嬉しく思います。

 さらに、月刊SOHOドメインさんのブログ特集で、アマヤホームさんの件が詳しく取り上げられていますのでビジネスブログに興味のあるかたはぜひご覧になってみてください。
追記:『月刊SOHOドメイン』に特集されました。経由:オンラインで読める(PDF)ようです。

PS.窓の杜大賞のノミネートの件では皆様暖かいご支援ありがとうございます。個人的には、開発者本人が投票しても良いのか悩んでいる内に投票期間が過ぎてしまった^^;のですが...。FireFoxやらiTunesとかある中で、BlogWriteが銅賞でも良いので、入賞したらすごいだろうなーと思います。結果の発表は明日の22日だそうです。

投稿者 BlogWrite担当 : 10:55 | コメント (0) | トラックバック

2004年12月06日

MSN SpaceでのBlog投稿API

マイクロソフト社に所属する、RSS Banditの開発者でAtomのMLで活発な発言もしているDare Obasanjoさん。今はMSN Space(MSが提供するブログ)のチームにいるみたいで、MSN SpaceでのBlog投稿APIを検討しているとか。

(以下超概要)
What Blog Posting APIs are supported by MSN Spaces?
Q.MSN SpacesではどのBlog投稿APIはサポートされてますか?
A.今のところどのAPIもサポートされてません。現在のXML-RPCのAPIではセキュリティ等がダメ。でも今検討中。例えば、

・Blogger/MetaWeblog API over HTTPS/SSL「Blogger/MetaWeblog API(XML-RPC)」
もっともツールが対応しやすい。
しかし機能的に足りない所がある。

・MSN Spaces specific API over HTTPS/SSL「MSN Spaces独自API」
独自APIではツールの開発者が大変である。
対応するツールも限られてしまうだろう。

・Atom API over HTTPS/SSL
予定では数ヶ月後に完成だが、予定が不透明である。
Atom Projectの予定に振り回されるのもどうか...

フィードバック歓迎....

だそうで...
どこも悩む事は一緒^^;

しかし、既存のXML-RPCのAPIでは機能不足、だから独自APIをXML-RPCで作る。そんな事をみんながみんな始めたら、破綻するのは分かりきっているわけです。
だからこそXML-PRCではなく、AtomのようなRESTで拡張性のある文書モデルを利用し、独自拡張機能はXMLに元々ある名前空間で対応しようという動きになった訳です。

ExciteさんとUbicastさんのやった独自APIはその破綻する方のやり方な訳です。

個人的に思う今現在のベストな対応方法としては、既存のXML-RPC APIにとりあえず対応し、独自機能についてはAtomAPIを待つ、という事だと思います。今検討されていらっしゃる方にはそうお勧めしています(例えば数ヶ月前にお会いした某社の方とかに...そろそろかな?)。

Atomはどちらにしても数ヶ月後になるのですが、なんにしてもDareさんこれまでAtomに結構貢献しているのだから、結果は見えてるような気がしないでもないですが....。どうでるか興味深く見てみたいと思います。

投稿者 BlogWrite担当 : 09:10 | コメント (0) | トラックバック

2004年12月04日

RSSとAtomは対立しない

RSSとAtomの話題がチラホラ聞かれるようになった最近。

個人的には、RSSとAtomの対立という構図ではなく、しばらくはRSSとAtomは共存し(これは予想)、上手く使い分けられていく(希望的観測)と見ています。

避けられない本当の対立という構図は、実はRSS自体にあると思います。RSSにはRDFベースのRSSとそうではないRSSの2系統があります。日本ではRDFベースのRSS1.0がどうやら広く使われているようですが、特にこれといった理由なく使われているケースが多い気がします。つまり、RDFという構文(多少複雑)を持ち込んだわりに、その利点がそれほど活用されていないと思えるケースが多々見受けられます。
逆に海外では、RSS2.0に代表されるRDFベースではない方の系統が主流となってきているという話を聞きます。

「RSS1.0 (RDF Site Summary) は失敗だ」と。

個人的にはどうなるかとても興味があります。

投稿者 BlogWrite担当 : 12:24 | コメント (2) | トラックバック

12月のメディア掲載

インターネットマガジン 2005年2月号 12月27日発売 
「BlogWrite」を紹介いただく予定です。

Yahoo! Internet Guide 2005年2月号 12月27日発売 
「BlogWrite」を紹介いただく予定です。

月刊SOHOドメイン 12月13日発売(http://www.soho-web.jp/)
「ビジネスブログ事例特集」の中でビジネスブログ構築事例として東横線賃貸デザイナーズのアマヤホームさんの紹介、その中でウィザシステムも紹介して頂くそうです。

Vectorで新着ソフトのレビュー
「HepCat」を紹介いただく予定です。

技術評論社 Software Design 2005年1月号 12月17日発売 
Atom記事執筆させて頂きました。

(以上順不同)

関係者の皆様ありがとうございます。
これからも頑張りますので、皆様どうか宜しくお願いいたします。

投稿者 BlogWrite担当 : 10:04 | コメント (0) | トラックバック

2004年12月01日

フィードの数と情報過多

前の記事でのHepCatと登録RSS数の件にトラックバック頂いてコメントも付けましたが面白い話題なので、ちょっとずれますが少しばかり掘り下げたいなとか考えます。

 丁度二、三日前に、IT Conversationsが配信しているMP3を利用して、Bloggercon IIIのOverloadというセッションを聞いていました。

 これは、Bloggerカンフェレンスでの「RSSなどにより最新の情報が沢山入手できるようになった。がそれと共に、情報過多という新たな問題が起きている。いかに大量の情報を重要なものを振り分け、処理するか」、というブロガー達による議論でした。

 日々自分のしている作業も振り返り分析しつつ、微妙に考えをまとめて見たいと思います。

 このセッションの司会はMicrosoftのRobert Scoble。彼は、957のウェブログを購読してるそうです。なぜ彼はそんなに大量にRSSを登録しているかというと、「top of the world」に居たいからだ、と言います。つまり、いつも技術やトレンドの最先端に居たいからだ、という理由からだそうです。
 が、このように大量のRSSを購読していると日々大量の記事を処理しなければなりません。解決策は何か...

 「ソフトウェア的にフィルターをかまして、重複した話題やゴミを排除する」という意見。

 これに関して、PubSubというRSS検索エンジンの開発者(Atom支持者)が、システム的に自動で検閲してしまう事の危険性を指摘。(ここでRSSの第一人者Dave Winerがぶち切れる^^;)

 ソフトウェアがフィルターしてしまう事の問題点とは、自分がすでに知っているまたは注目している話題しか入ってこなくなってしまう、つまり新しい発見をする事が出来なくなってしまうという欠点です。さらに、重複した話題を扱っている記事でも、その重複しているという事自体に意味があり、例えば3人の人が話している話題はきっと重要であろう、などと判断する事が出来ます。
 Scoble曰く、「私としてはフィルターされた情報ではなく、生のあなたを知りたい」と。

 Dave Winerがぶち切れたせいで、ココで話題が技術的に解決する事から別の解決策の方へ移ります。参加者の人が曰く、「私は情報をフィルターするのに人を使っている、例えばScobleとか」と。

 つまり、Scobleのような情報通、早耳で頭が良い人の書いているBlogを購読することによって効率的に重要な情報を得ていると。個人的にこれ良いナーと思いました。

 そこで、Attention.xmlというのものに注目が集まるわけです。Attention.xmlとは、ある人が読んだもの、注目している事などを公開するための皆で決めてる策定中のXMLの規格の一つです。しかし、プライバシー的にどうかと思う訳で、自分が読んだものではなくて、いっそ逆に自分が読まなくなったものを公開した方が良いのではないかとかいう話...。

 他にも、Blog等の配信側に出来る事として、Blogのカテゴリーが役に立つと。カテゴリで整理した情報が読み手にとって必要な情報を得るために役に立つと。このBlogでも、BlogWriteやHepCatに関した専用カテゴリを設け、カテゴリ毎にRSSを用意しています。また、リンクBlogを用意して、自分が購読しているBlogのリストを公開する事によって自分がどれに重要度を置いているかを読者に提示することが出来ます。

結論

結局、自分と似た興味を持ち、かつ早耳で頭いい人のブログを登録しておく、というのが一つの方法かなと。「人」を利用した情報抽出ということです。その「人」を見つけるには結局多数のRSSを登録したり、検索しなければわからないわけですが、そのうちある程度の数に落ち着くのではと思います。
 例えば、Blog界隈のニュースを追いかけるにも、初めは全てのBlogサービスのRSSをそれぞれ取得していましたが、BLOG界の出来事のRSS一つで済むという事に気付きます。他にもあの人やあの人の情報を押さえておけば大丈夫、みたいな事があると思います。

 同じような事は、リアルな人間関係でも似たような感じで起きている事なんじゃないかなぁと思ったりします。

投稿者 BlogWrite担当 : 11:28 | コメント (0) | トラックバック

2004年11月17日

Atom記事脱稿

とりあえず、脱稿しました。まだ校正など残っていますが...。

来年一月号の特集記事で、4部構成。本来は4人で書くようなものを何故か一人で書かせて頂きました。

「次世代WebテクノロジAtom」みたいな感じで、
第1章は、RSSの歴史、現在、そしてAtomの生い立ちまでの概要解説

第2章は、Atomフォーマットの詳細解説、最新版の仕様にも触れる

第3章は、AtomAPIについて解説。Atom Publishing Protocol(ほぼ完全解説)。

第4章は、AtomAPIの利用法という事で、AtomAPI対応ソフトの紹介や簡単なスクリプト等の紹介。

原稿用紙にすると、コードなどを除き、文字だけで100枚以上になると思います。個人的には、メインコンテンツは第3章だったりします。発売される時はまた改めてここでお知らせさせていただきたいと思います。

という事で、私が関係している幾つかの進行中プロジェクトが停滞してしまって大変申し訳ありませんでした。(業務連絡)
公開中のソフトウェアの更新も含めて、これからバリバリ頑張りますので、みなさまよろしくお願いいたします。

追記:2005/03/05
記事オンライン公開しました。
解説 Atom - Atomとは何か: RSSやXML-RPCとの比較、AtomAPIの使い方まで

投稿者 BlogWrite担当 : 02:34 | コメント (1) | トラックバック

2004年11月15日

Comment API

The Comment API

そう言えば,あまり知られて(同時に使われても)いませんが,ブログへコメントするためのAPIというのがあります.


POST /news/comments/5 HTTP/1.1
Content-Type: text/xml

<?xml version="1.0" encoding='utf-8'?>
<item>
<title>Foo Bar</title>
<author>joe@bitworking.org</author>
<link>http://www.bar.com/</link>
<description>My Excerpt</description>
</item>


のような感じ.
これは、HepCatなどのRSS・Atomリーダ(アグリゲータ)でウェブログを閲覧しながら,ソフトウェア的にコメントできるようにするもの。

さらには,TrackBackを打つ

POST /news/comments/5 HTTP/1.1 Content-Type: text/xml

<item>
<title>Foo Bar</title>
<link>http://www.bar.com/</link>
<description>My Excerpt</description>
<source>Foo</source>
</item>

この方法でTrackBack打つと文字化け無いです.今のとりあえずUTF-8で...みたいな暗黙の了解が無くなってすっきり。おまけに拡張も出来る。


でも、これらを実装することをお勧めしません。
いずれ、AtomAPIと統合されると思われるため….しないとしても,変わる可能性大。
しかも、昨今のコメントスパムをみると....。TypeKeyとかを使ってゴミをフィルターしないと、イヤーな事になりそうです.

使えたら便利なんですけどね...

投稿者 BlogWrite担当 : 19:03 | コメント (0) | トラックバック

2004年11月13日

Atomはほぼ完成した?

AtomのWGメーリングリストでの話が結構反響になっています。

Tim Bray氏の提案だったのですが、あと幾つかの件を詰めればAtomは完成であると。

大方の反応はまだだろう。という感じなのですが、Tim Bray氏のブログにこの件について面白い話が載っていました。

今はSunで働き、以前はXMLの裁定に関わった氏曰く、RSSとAtomの関係は、XMLにたいするSGMLのようなものである、というような事を言っています。
さらに、RSSに対して、Atomに革新的な機能が無ければいけない、なんてことはないんだ、とも。

RSSとAtomの関係は、SGMLとXMLと比較するにはちょっと大げさすぎるけれど、位置付けは間違っていないかもしれない、と思います。


RSSとAtomのどちらが優れているのかなどというという話はゴメンです。

どっちも良い。

問題は、両者がどう異なるのか、どういう場面で最大限活用出来るか、という事を正しく知る事が重要だと思います。つまり、個人的には、どちらも状況によって適したものを使える自由というものを支持しています。

追記:
Scoble and ATOMでは、RSSに対する健全な競争を促すためにAtomの出現は必要だという。お互い競争することで、両者がより良いものになる、と。ただし、問題は...RSSはこれ以上変更されることは無い、と公式に宣言されている事ですが...。

投稿者 BlogWrite担当 : 13:03 | コメント (0) | トラックバック

2004年11月09日

ノキア、AtomAPIクライアントを搭載した携帯発表

ITmediaモバイル:Nokia版“おサイフ携帯”やBlog携帯も~Nokiaが新モデルより引用、

最大の特徴は640×320ピクセル、6万5536色のタッチスクリーン。ペン入力による手書き文字認識も可能だ。1メガピクセルカメラを搭載し、インターネットWebブラウザや電子メール、PIM、MP3音楽プレイヤー、FMチューナー、WebLog機能の「lifeblog」など、ハイエンドな電話機能とエンタテイメントの要素を併せ持つファッション端末。
モバイルでのBlog利用にも対応。内蔵のmoblogクライアントを使えば、ブログサイトに写真やテキストをアップロードできる。

あれ、もう出たの?えっ?

HepCat Dev and Test: Nokiaの携帯でAtomを利用したBlogへの投稿が2005年初めには可能により引用、

「Nokia のLifeblogはオープン標準のAtomにより実現され、2005年初めには利用できるようになる。」

のSixApartと提携してサービス展開するという,ノキアのAtomクライアントですよね...。


そろそろ携帯買おうっと.....。

auだとアプリ作って楽しむ事が出来ない(Brewは"勝手"アプリ作れないらしい)から,結局ボーダフォンか...ウムム。

投稿者 BlogWrite担当 : 13:40 | コメント (0) | トラックバック

2004年11月07日

「MobileAtom J2ME」携帯のJavaアプリでAtomAPIを実装

いくつか前のエントリでも書きましたが、まだ日本語ではまったく紹介されていないことに気が付いたので、改めて。

「MobileAtom」

AtomAPIをJ2ME搭載の携帯端末から使えるようにしたアプリ。前に話題になった「AtomME」とはまた別のものです。
まだアルファのバージョンです。

J2ME だと PUT/DELETE のメソッドが使えないため、AtomAPIのSOAPバージョンを利用します。SOAPバージョンではX-WSSEのヘッダをつけるのではなく、SOAPエンベロープ内に認証情報を含めますのでヘッダを追加できない携帯環境からでもAtomを使えます。

サンプルでは、投稿をAtomAPIのRESTバージョンで行ない、削除と編集をSOAPで実行しています。

書いたのは、AtomAPIのCo-editorのRobert Sayre氏

投稿者 BlogWrite担当 : 11:39 | コメント (0) | トラックバック

BloggerのAtomAPIアップデート

先日、ここや、ここでアナウンスしたように、BloggerのAtomAPIがアップデートされ、BlogWriteで過去記事を取得すると日本語が化けるという問題がやっと解消されました。

これで、BlogWrite経由でBloggerを存分に使えるようになりました。

投稿者 BlogWrite担当 : 11:20 | コメント (0) | トラックバック

iアプリなXML-RPCクライアント

あそびをせんとやうまれけむ: 携帯電話が直接XML-RPCをしゃべる経由
YappoLogs: iアプリなXML-RPCクライアント配布開始しましたより引用、

Movable TypeのXML-RPC APIに対応したDoJaなクライアントの一般配布を始めました。

だそうです。(というか、よく見たらトラックバックもらっていた..orz)
ここでも話題になった、
Nokiaの携帯でAtomを利用したBlogへの投稿が2005年初めには可能に
携帯でAtomによるBlogクライアントの技術的問題点と新しい提案

携帯でブログを編集するiアプリ公開されたようです。面白そうですね。

で、あやまらなくてはならないのは、携帯でAtomするにはHTTPのヘッダが問題になるという事で、回避策があったけど改めて報告するといったきり、してなかった件です。ごめんなさい。

ということで、携帯でAtomする「MobileAtom」を紹介したいと思います。
「MobileAtom J2ME」携帯のJavaアプリでAtomAPIを実装こちらで、スクリーンショット付きの非常に詳しい解説があります。ソース付きです。

携帯でAtomクライアントを作成するのには、とっても参考になるのではないでしょうか。日本の携帯でも動くようになったら嬉しいですね。

投稿者 BlogWrite担当 : 10:08 | コメント (0) | トラックバック

業界標準を無視したエキサイトブログのXML-RPC

ついに、恐れていたことが現実のものとなってしまいました。

「旅行びと日記」日記: エキサイトブログがXML-RPC対応・・?より引用、

ubicast Bloggerがエキサイトブログに対応したとのこと。
で、ということはXML-RPC機能に対応してきたのかなと思いエキサイトでリリース文なんかを探すものの、発見できず。
「???」
という状態で色々調べてみたんですが恐るべきことが判明(萎・・

詳しくは上記リンク先を読んでいただくとして、何が問題かというと、
すでにある「業界標準」仕様を無視したプロプライエタリな独自仕様
混乱を避けようというBlog界の動きを完全に無視した動き

また、これらは混乱をもたらすものでしかなく、ユーザをも無視したものでもある、と言えます。

海外では、競合する各社でも開発者どうしが協力しあって、積極的に標準的な仕様を裁定しようとがんばっているさなかに、こういった独断的に協調や連携を阻害するような事をすると、せっかくのBlogにおける利便性が損なわれることになります。

RSSやAtomにしても、標準仕様というのがあって、みんなが同じものを使えるからこれだけ便利になり、種々のツールやサービスが生まれました。

オープンな標準と相互運用性がキーなのです。

市場においてある程度の位置にある一社がそれを無視した動きをするのは、おそらくは無知からきたものだと思われますが非常に残念であります。

おそらく、エキサイトとubicastさんの中の方たちは、Atom APIというものをご存知ないのかもしれません。これは、私もいままで積極的に情報を発信してきたつもりですが力不足の面があったかもしれません。また、Atom APIに関して日本語の情報がまだ少ないという事もあるかもしれませんね。

そういう事もあり、ちょうど今、技術系の雑誌にて、Atomについて記事を執筆させていただいています。ここにて、XML-RPCとAtomAPIについて詳しく書かせていただきました。XML-RPCにおける混乱を懸念していましたが、間に合わなくて本当に残念です。

投稿者 BlogWrite担当 : 09:29 | コメント (0) | トラックバック

2004年09月22日

The Atom Project

Atom Project [PDF] by Tim Bray and Paul Hoffman.

Atomのエライ人、Tim Bray and Paul Hoffmanによるプレゼン資料。Atom界隈の現状が上手くまとまっています。
後ほど日本語訳します。

投稿者 BlogWrite担当 : 00:00

2004年08月25日

Atom over Jabber[解説]

Blog.BulkNews宮川氏の記事

Atom feed のアップデートを Jabber 上の XMPP (eXtensible Messaging and Presence Protocol)ってなプロトコルで通知する IETF draft。
Atom over Jabber
の解説。

この、氏曰く「Atom feed のアップデート」とは、Atom形式で配信された個々の記事の「削除」、「更新」イベントなどを指し、そのイベント情報をPush形式で通知するするために、JabberでのXMPPの拡張を利用するというもので、XMPPの拡張によって流れるのはイベント情報を表すAtom形式になります。

これが利用可能となれば、ユーザーはリアルタイムに新規記事が公開された事を知ることが出来ます。

いきなりこれを読むと、そこまでしてFeedの更新情報知る必要なんかない、と思うのですが...。この仕様案は、どちらかというとBtoBをターゲットとしている感があります。すでにニュース記事配信仕様としてNewsML(日本では毎日新聞などが採用している)がありますが、このNewsMLで似たようなことを実現している記事のステータス情報部分(つまり、公開可、更新、取り下げ、削除など)をAtom Feedから分離してXMPP経由で実現しよう、という背景があります。

Atom Feedとは別途こういった仕組みにしたのは良いと思います。使わない人は使わないで必要な人は使えるわけですから、今までのRSS/Atomアグリゲーターでの方式に変更をせまりません。

メーリングリストを読んでいると、出版関係の方々がこういった仕組みを利用したいようです。

ちなみに、知る人ぞしるJabberというのはチャット(最近ではIMというらしい)のソフト(仕組み含む)の事で、RSSやAtomと同じくXMLを利用しています。それを拡張して最近はこのような事にも利用されるんですね...

「どちらかというとBtoBをターゲットとしている感があります」と書いたわけですが、リアルタイムに情報を取得するというのもアリで、実際PubSubという海外のサービス(日本でいうBulkNewsやFeedBackのようなサービス)ではpubsubxmppというのがあって、キーワードにマッチした記事がリアルタイムに通知されるサービスが存在します。

つまりキーワードを登録しておいて、IMのようなものを立ち上げておくと、キーワードにマッチした新規記事がリアルタイムに通知されるわけです。ここでいうリアルタイムとは本当の意味でのリアルタイムで、ライブドア社が発売するRSSリーダーNewz***の宣伝文句(マーケティング用語)での”リアルタイム”ではありません。IMの会話なみのリアルタイムです。所謂Push型とPull型の違いです。

個人的に思うことは、この仕様はもし裁定されたとしても、すぐに流行ったりはしないだろうなと。しかしながら、参加している人などを見るに...ApacheなどのWebサーバーに組み込まれたり、通知を受ける仕組みがFireFoxやMozillaなどのブラウザーに組み込まれる可能性があるので、そうなると実装するのも楽になり、利用する人も増えるのではと思います。

投稿者 BlogWrite担当 : 23:38 | コメント (0) | トラックバック

2004年08月17日

Atom PP実装はまだ早い?

Atom API(正式名称はAtom Publishing protocol)のメーリングリストで、AtomAPIを実装して一般マーケットに公開するのはまだ時期尚早であるとの意見が流れています。

曰く、Atomの仕様はまだドラフト(下書き)の状態であるにも関わらず少なくとも二つの大手ベンダーが近くAtomAPIに対応したソフトウェアを公開するかもしれないという。まだ仕様が固まっていない状態でのAtomを元に製品を一般市場に公開するのは差し控えるように要望した方が良いのではないか、という。

ではBlogWriteはというと、ここでいう大手ベンダーでも何でもないので^^;気にしませんし、仕様が正式になったら対応サービスの様子見ながらアップデートするだけですが...。確かに大々的にやるには時期尚早かも、でなくて、時期尚早ですね。

という事で、いきなし仕様変更とかしないでくださいね(半泣)ー>Livedoorさん。

正式発表されたら、どんなサービスが生まれるのか、いまから非常に楽しみです。「AtomAPIを利用したショッピングサイトの構築+運用」とか...。これが出来ると便利なんですよ、なんせローカルPCの商品データベースと連携とれるから、商品情報とか一々入力しなくてすみますから。

投稿者 BlogWrite担当 : 02:14 | コメント (0) | トラックバック

2004年07月23日

Atomプロトコル (Atom API) の可能性:不動産業界での例

The Atom Publishing Protocol(以下Atom API)を現実的な視点から少し考えを文章にしてみたいと思います。

Atom APIコンセプトが実際に有用であり、単なる卓上の話ではない事は、Atom APIの'Proof of Concept'でもあるBlogWriteが実証していると思います。

元々、主にBlogなどでの利用を想定して裁定が進んできたAtom APIですが、現在、用途を限定しない方向にシフトしています。
さらにXML-RPCと違い、Atom APIを利用するとXMLの利点をフルに活用した拡張を行なう事が容易になります。Atom APIのコアの部分とその拡張性を生かしてどんな事が出来るか、を考えました。

不動産業界

各不動産会社はインターネットの各種サイトに日々物件情報を掲載しています。空き物件は日々入れ替わり、毎日のようにウェッブ上の物件情報を修正する必要があります。さらに、一つの物件につき多数の項目が存在し、掲載するメディアも幾つものサイトに渡るため、その負担はそこそこのものといって構わないでしょう。

では、実際にはどのようにしているのか、というと...。

ある社は印刷された紙媒体を専用業者に委託してウェッブに掲載させている。自社ウェッブサイトがない、またはあまりWebの知識がない企業。大多数がこれである。更新が遅いため掲載物件がうまってしまった時など致命的である。

または、管理物件を管理ソフトを使いデータベースで管理しているケースの場合、ソフトからCSVなどをFTPでソフト専用のサイト等に物件情報を登録している。汎用性やソフト間の互換性はまったくない。結局多数のサイトに掲載するには、ブラウザベースの登録フォームに決まりきった多数の項目を毎回ひたすら手で入力するのである。


もしこれが、物件情報を管理する管理ソフトウェアと不動産ジャパンなどの全国的な不動産物件検索サイトがAtom APIを通して連携したらどうなるだろうか。

不動産会社は自社で利用している管理ソフトウェアからボタン一つで好きな物件情報を全国レベルのサイトにモノの数秒で簡単に登録できるようになるはず。

また、Atom シンジケーション フォーマット で物件情報をエクスポートすれば、XSLTなどを利用して簡単にWebと連動した印刷媒体も作成可能になるのです。

さらに、不動産検索サイトにおいて、検索条件を登録しておき、その検索結果をユーザーがAtom シンジケーション フォーマットで取得できるようにすればユーザーはRSSリーダー等を使い特定の条件の物件だけをタイムリーに取得できたりするのです。

では何故そういった動きがないのか。以下のリンクが参考になるかもしれない。


もしも天気予報がXMLだったら - その1 XMLとは?

もしも天気予報がXMLだったら - その2 できない理由


不動産業界でも実体は似たり寄ったりで、日本の構造的な壁がまた浮上してくる。

さらに、本家Yahoo!の技術力とブランド力だけのYahoo! Japanにとっては不動産コンテンツ掲載は重要な収入元であり、Atom APIやXMLによって一般にもたらされるパワーを恐れその利用に反対している。 またイサイズなどを運営している情報流通大手リクルートは自社内ネットワークの情報一本化に手一杯であり、不動産情報流通に新たな技術を持ち込む余裕がないという。

そういった旧弊を打開するには、やはりライブドアのようなヤンチャ者が必要なのかもしれない。

投稿者 BlogWrite担当 : 20:06 | コメント (0) | トラックバック

2004年07月21日

Atom API利用時の追記、改行指定等について

LivedoorBlogをご利用の皆さんに不便をおかけしております。

AtomAPIを採用しているLivedoor Blogでは現在の所、追記や改行のサポートがありません。なので、LivedoorBlogのBlogの設定において自動改行をオフにして頂かないと、投稿時に勝手に改行が付加されて しまうという状況が起きています。

この問題を解決すべくLivedoor Blogの担当者の方にもお願いしていますが、AtomAPIの仕様に関してもこれらの オプションを有効に出来るようにすべく、各方面に働きかけております。

という事で、LivedoorBlogユーザーの皆さんもうしばらくお待ちください。





今の所、以下のようなものを考えています。

<?xml version="1.0" encoding="utf-8"?>
<entry xmlns="http://purl.org/atom/ns#" xmlns:mt="http://www.movabletype.org/atom/ns#">
<title>My Entry Title</title>
<created>2003-11-17T12:29:29Z</created>
<content type="application/xhtml+xml" xml:lang="en">
<div xmlns="http://www.w3.org/1999/xhtml">
<p>Hello, <em>weblog</em>world!</p>
<p>This is my first post<strong>ever</strong>!</p>
</div>
</content>
<mt:allowComments>1</mt:allowComments>
<mt:allowPings>1</mt:allowPings>
<mt:convertLineBreaks>1</mt:convertLineBreaks>
<mt:trackBackPings>
<mt:ping url="hoge" />
<mt:ping url="fuga" />
</mt:trackBackPings>
<mt:textMore type="application/xhtml+xml" xml:lang="en">
<div xmlns="http://www.w3.org/1999/xhtml">
<p>You are reading more text.</p>
</div>
</mt:textMore>
</entry>

投稿者 BlogWrite担当 : 09:48 | コメント (0) | トラックバック

2004年07月17日

インターネットマガジンAtom特集

インターネットマガジン2004年8月号立ち読み

本誌2004年8月号緊急レポート「ウェブを新たなメディアに変える『Atom』の正体」冒頭部分128~129ページの記事(テキストのみ)の立ち読みができます。本誌上では図、表、イメージを交えての解説となります。

ウェブを新たなメディアに変える「Atom」の正体

これから買いにいってきます。

投稿者 BlogWrite担当 : 13:33 | コメント (0) | トラックバック

Atom API ー>Atom Publishing Protocol

Atom-Syntaxというメーリングリストで、自分の質問が仕様になった件で 新しく出た仕様書を読んでいて気が付いたのですが、 Tim氏のBlogのエントリーで気になった表現がありました。

The first Internet-Drafts of both the Atom Format and the Atom Publishing Protocol (previously known as the AtomAPI) are now available.
「The Atom Publishing Protocol(previously known as the AtomAPI)」 つまり、「今までAtomAPIとして知られてきた Atom Publishing Protocol」って事は正式名称また変わった模様...

今後はAtomAPIではなく、Atom Publishing Protocolという事に...


さらにTim Bray氏へのインタビューを含む この記事(英語)によると、 先日あった、Atom関連の仕様をW3Cで裁定しないか、という話は蹴って、IETF(Internet Engineering Task Force)で仕様の標準化を行なうという。 さらに、10月の終わりには安定版のドラフト仕様を完成させる予定で頑張っているとのこと...。

投稿者 BlogWrite担当 : 09:37 | コメント (0) | トラックバック

LivedoorのAtomAPIについて

いつのまにか(おそらく今日?)、 この記事のコメントにある問題が修正されている事に気が付きました。 これで、LivedoorBlogでも問題なく投稿出来ます。担当の方お疲れさまです。

しかし、Livedoorが利用しているAtomAPIでの問題なのですが、幾つか不都合な点があるので、改めて整理して見ます。

追記

すでに追記がある記事をAtomAPI経由で取得すると、追記が本文に含まれてきます。それで、その記事を更新(Put)すると すでにある追記はそのままで、記事に埋め込まれた追記と重複してしまいます。

以前は”続きを読む”というリンクが埋め込まれていましたが、これがかわりに追記文そのものが記事本文に埋め込まれて 来たという感じです。

個人的には、単に追記はまったく含めずに記事本文だけ編集できたらと思います。将来的にAtomAPIで追記のサポートがあるかも知れませんし...。

改行

AtomAPIでは、”自動改行”などといったオプションがありませんので、BlogWriteでの記事投稿時に改行の設定をコントロール できません。それで記事投稿すると、LivedoorBlog側の改行の設定になってしまいます。デフォルトは自動改行ですので、 何もせずにBlogWriteから投稿すると、HTMLにさらに改行を付加してしまいます。HTMLタグの中に改行タグを入れて しまうケースもあります。

AtomAPIの仕様にまだ無い件なので、難しいと思いますが、とりあえずの回避策として、 AtomエントリーのContentタグのType属性が、text/htmlまたはapplication/xhtml+xmlだった場合は自動改行処理を 行なわない。text/plainだった場合は自動改行処理を行なうなどはどうでしょうか。

投稿者 BlogWrite担当 : 00:47 | コメント (2) | トラックバック

2004年06月30日

ココログ Atom API の小さくて大きな問題

という事で、BlogWriteを使ってココログ試してみました。まず、XML-RPC経由ではとりあえず問題なく投稿出来ました。 観測気球さんが教えてくれたカテゴリーの件は後でゆっくり調べます。

でAtom APIの問題(厳密にはWSSEの)。(技術的な話になりますけどすみません。)

Atom APIでは認証にWSSEというのを使います。これが問題です。

現在BlogWriteでは、LivedoorとBloggerでAtom APIでの投稿を確認しています。そこで、ココログ(つまりTypePad)でAtom APIを試そうと思うと、

X-WSSE PasswordDigest is incorrect
というエラーが返ります。簡単に言うと認証に失敗した、という事です。

で、なぜBloggerとLivedoorBlogでOKで、ココログではダメかというと、WSSEのPasswordDigestの扱い方法が違うんです。やばいです。 みんながみんな自分の方法でやってるような物で、こういったのはしっかり仕様で決めないとよくないです。 TypePadのAtom API(仕様)には、

base64(sha1(Nonce . Created . Password))として、作成した物をHTTPのヘッダーに以下の様にして送信する
X-WSSE: UsernameToken Username="Melody", PasswordDigest="VfJavTaTy3BhKkeY/WVu9L6cdVA=", Created="2004-01-20T01:09:39Z", Nonce="7c19aeed85b93d35ba42e357f10ca19bf314d622"
とあります。実際そうなんですが、これだけでは仕様が不十分です。穴があります。WSSの穴。 だから[Blooger、LivedoorBlog] 対 [TypePad(ココログ、ブログ人)、(そしておそらくMT3)」]で違いが出来てしまうのです。

で、仕方が無いので、いったんココログのPasswordDigestの扱いにあわせて送信すると、観測気球さんの報告( ココログで Atom API を使ってみる)にあるように、

Can't call method "type" on unblessed reference at /usr/local/lib/perl5/site_perl/5.8.1/XML/Atom/Thing.pm line 95.
というエラーが返ります。(このエラーはおそらくAtom APIの処理でバグっているのだと思いますが中の人ではないのでなんとも言えません。)

という事は、観測気球さんはおそらくココログではとりあえずテスト出来ているが、BloggerやLivedoorでAtom APIのテストをしようとすると、「Invalid Login」とかなってしまいませんか? Atomクライアントは少ない(個人的にはecho、echo for win)しかしらない。echo for winはやっつけでやったのでテキトウらしいし、どの道、 echo for winは一度もまともに動いた事が ないので(言い過ぎ)テストしませんが、今後大きな問題になるかと思います。

で、肝心のどこがどう違うんだよ!という質問は、企業秘密なのでお答えできません。ー>嘘 あとでしっかり調べてしっかり書きます。

現状ではどっちに合わせようか悩む所なのですが、ココログにはXML-RPCがあるし、ココログのAtomサポートはココロもとないので、今まで通りBloggerとLivedoor Blogに合わせます。



は!という事はココログで一ヶ月以内にちゃんとAtom APIがサポートされないと、自分の支払った250円が意味無いじゃん...俺の金返せ~...。冗談です。

投稿者 BlogWrite担当 : 14:01 | コメント (5) | トラックバック

2004年06月29日

Atom API 対応 BlogWrite 0.9.4

BlogWrite Beta 0.9.4
BlogWrite Free 0.9.4(無料版)

今回、BlogWriteは、Atom APIに対応しました。よって日本ではLivedoor Blogにも投稿できるようになりました。 また、海外ではBlogger.comにも対応しました。 これで、現在確認済みの対応サービスは、以下のようになりました。
Movable Type 2.xXML-RPC確認済み
Movable Type 3.0XML-RPC、Atom APIXML-RPCのみ確認済み
TypePadXML-RPC、Atom API未確認(XML-RPC動作報告あり)
(ココログ)XML-RPC、Atom APIXML-RPC動作確認、AtomAPIはペケ(注3)
(ブログ人)XML-RPC、Atom API未確認(XML-RPC動作報告あり)
Livedoor BlogAtom API確認済み(注*1)
Seesaa BlogXML-RPC確認済み
BloggerAtom APIAtom APIのみ確認済み
News-HandlerXML-RPC確認済み(注*4)

(注*1) しかしながら、一部(サービス側の)不具合を発見しているため(すぐに修正されると思いますが) 一部動作しない所があります。例えば:とか (新規投稿した直後はそのままエントリーを編集しようとしても出来ない。過去記事の取得の操作をすれば出来る)

(注*3)ココログ Atom API の小さくて大きな問題参照。

(注*4)投稿日時を設定しないと投稿できない問題があります。サービス側の不具合です。

という事で、今回のAtom APIのサポートは完全に動作確認しきれていないので、Atom APIのご利用は計画的に...
もし不具合を発見された方はご連絡いただけると助かります。(サービス側のバグでも構いません)

あ、誰も見ていないさんがNUCLEUS環境での詳細なレポートを書いてくれてます。 ちゃんと見てます;-)。NUCLEUSはちょっと今度じっくり検証してみなくてはと思っています。もうしばらくお待ちください。 頂いた要望とエラー報告もしっかり調べてます。ビックリするほどしっかりした報告ありがとうございました。


誰も見ていないさんの所でしったのですけど、JugemってNUCLEUS使っているのですね。道理でURIが似てると思った... って事はXML-RPC対応はとっても簡単なはずでは?(日本語マルチバイト処理で引っかかるのですけれどね...)勘違いだったらしいです。。:-)

とか圧力かけて見たい...のはほんの冗談です。

話変わってタイガー(OS X Tiger) http://www.apple.com/server/macosx/tiger/
ウェッブログ サーバーが内蔵され、 XML-RPCやAtom APIがふっつーに使える...! すごいですね...。

投稿者 BlogWrite担当 : 12:54 | コメント (7) | トラックバック

2004年06月24日

livedoor blogの Atom API

blog.livedoor.com Atom API Specによると、

XML::Atom::Client: 日本語は UTF-8 bytes で入れると、base64 エンコードされる。 # UTF-8 文字列でいれるとサーバエラーになる>調査中

既知の問題: dc:subject にマルチバイト文字列で syswrite エラー

ってーゆーと...もしかして使えない...?
XML::Atomと言えば、MovableTypeやTypePadを作ったBenさんが(主に?)作って、Miyagawaさんとかパッチかましてる奴だから、MTやココログでも同じなのかも...
そういえば、MTのXML-RPCでエラー文字列に日本語文字列混じると日本語復帰できないBase64エンコードの文字列が返ってくる 気持ちの悪い仕様と同じだ。
ココは一つ大和魂こめて頑張ってください>中の人。解決お疲れ様でした。 Base64の方は当方の誤解だった模様。

AtomAPI対応はもうしばらくおあずけです。対応しても使えないのじゃ意味ありませんから...着手して見ます。
しかし、どこまでも付いて回るマルチバイトの罠。

Atom APIを使うと、カテゴリの取得、設定が曖昧(出来ないというかなんというか...)なのは分かります。 なんといってもまだ標準化されていませんから。ましてや独自実装でAPIの乱立はやはり避けたいし。

投稿者 BlogWrite担当 : 14:18 | コメント (6) | トラックバック

ライブドアBlogがAtom APIに対応

Livedoor BlogがAtomAPI に対応したそうです。これからBlogWriteのAtomAPI対応版に着手するかもしれません...。

って事はLivedoor Blogにアカウント取らねば...いったい幾つのBlogをもっているのか....10以上?

投稿者 BlogWrite担当 : 04:06 | コメント (0) | トラックバック

2004年05月18日

Atom API vs XML-RPC

Blogエディタを開発中であるわけなのですが、 (このエントリーもそのBlogエディタで書いているのは秘密です)結局AtomAPIではなく今の所はXML-RPCでいこうかと思います。 本来はAtomAPIで行きたかったのですが、これや諸般の理由により AtomAPIの実装はとりあえず断念します。

以降、何かの足しになればと思い公開するものであり、技術的詳細やら長話に興味がない方には申し訳ありませんが あまり興味のある話ではないかと思いますのでご了解ください。 (とか言いつつ、Blogエディタのテストがしたいだけじゃないのかという話も聞こえる)

改めてですが、Blog本体と通信し更新などの処理を行なう方法で今現在一般的なのは、XML-RPCと言われるものです。 大抵の(と言っても少ない)BlogエディタはXML-RPCで実装されていて、クライアントソフトウェアーサーバー間の 通信にXML-RPCが用いられています。

しかし、個人的に前からどうせ作るのならXML-RPCではなく、Atom APIでと思い一人去年から騒いで (..) (..) いたのには理由があります。

Blog関連に絞ったウェッブ上のリソース管理パブリッシングプロトコル(長い)として非常に強力であると認識したと同時に 現行の方法では解決できない問題を幾つか解消しつつ新しい機能を実装できるからです。 以下、つらつらとAtomAPIについて、またXML-PRCとの簡単な比較などつらつらと書いて見ます。

国際化について

・XML-RPC
ちょっと前まで、仕様により文字列に日本語などのマルチバイトを使用出来なかった。 また、日付のタイムゾーンの指定が仕様で明示的に禁止されているため、混乱が起きやすい。
・ATOM API
多分問題なし。

拡張性について

・XML-RPC
データ型の規定が存在する。利用できるメソッドを指定できる。 そのため、汎用性があるが、拡張性に乏しい。 元々は名前が示す通り、リモート呼び出し手続きに利用される。
・ATOM API
ウェッブコンテンツ更新等のために今現在裁定されつつある新しい規格。 名前空間を利用したりして、拡張するのが容易。

セキュリティについて

・XML-RPC
セキュリティ特に決められていない(?)。 今現在、Blogなどを更新するケースでは、パスワード自体が(暗号化せずに)平文で送信される。 (ブラウザーでの更新も同じ)
・ATOM API
SHA1で生成した、160ビットのハッシュ値を送るため安全性が高い。 生成されたハッシュ値からパスワードを得るのは現在の所、不可能。


より細かい比較、というかAtomの利点については、本家SixApart社のページ(英文)を参照ください。 Why We Need Echo (EchoとはAtomの旧名)

付け加えるべき利点といえば、もうだいぶ解消されてきた模様ですが、 TrackBackの文字化けも、対症療法ではなく原因から根本的に解消されます。

ずいぶん前に書いたATOM関連のエントリー
Atom and Its API

更新PingやTrackBackPingが実装されてればそれでBlog完全対応!で終わらせられるのがちょっぴり 残念で、出来れば多くのBlog関連のサービスやツールが、少なくともXML-RPC、できればAtomAPIの実装にも 力を入れていただきたいと思うこのごろでした。




投稿者 BlogWrite担当 : 17:55 | コメント (0) | トラックバック

2004年02月15日

Atom Auto Discovery テスト スイート

Auto Discoveryとは、通常のHTMLのウェッブページ内にRSSやAtomへのリンクを埋め込んでおいて、それを種々のアプリケーションが見つけて利用できるようにするための決まり事(仕様)です。

Atom autodiscovery test suite でこの仕様に対応しているかどうかテストできます。

HepCatは、XHTML1.0とHTML4のそれぞれ56のテストにすべてパスしました。
拡張子がRSSやRSF、XMLなどのリンクも探すので、これでおそらくまずほとんどのRSSとAtomフィードを発見出来るでしょう。

ただ、今回はXHTML1.1のテストは確認できませんでした。
というのも、IEの「MIMEタイプが『Content-Type: application/xhtml+xml』のものをダウンロード(保存)しようとする」という習性(バグ)のため。

「ツール」ー>「表示ページからフィードを探す」でAuto Discoveryを試すことが出来ます。

投稿者 BlogWrite担当 : 05:13 | コメント (0) | トラックバック

2004年01月29日

TypePadのAtom API

TypePadでAtom APIのベータサポートが実装されたようだ。

しかし、クライアントでAtom APIを本格的に実装するのはまだ早そうだ...

2004/06/29 追記:BlogWriteという名前でAtom API対応のBlogクライアントを公開しました。


TypePadとAtom APIの技術情報のページ
TypePadのAtom API

投稿者 BlogWrite担当 : 10:45 | コメント (0) | トラックバック

2004年01月24日

Atom and Its API

--HepCatの開発メモ(ATOM)--

そろそろ、待ちに待ったATOM APIの実装に手をつけても良い頃だと思う。

RSS を利用した新しいサービスが次々と登場している中、
開発者達に注目されている次世代フォーマットのAtom だ。
TypePad (ニフティでも採用)や MovableType 2.65 で正式対応された。

また、大御所BLOGGERでも 正式対応が発表された。
AtomEnabled.org のサイトが立ち上がり、開発者の為のAtomに関する最新情報などが公開されている。

しかし、誤解が多いようなので、ここで簡単に説明したい。

ATOMはRSSやRDFの代わりになる物、というだけではない。
ATOM API という仕様一式が存在する。

Atom Project

 以下、AtomProjectのサイトより、引用&意訳

 ---ATOMの想定される目的-
 *Feed : Use for computer-friendly syndication (similar to RSS in functionality)
 (今のRSSのような物)
 *Editing : Use between atom-enabled clients and servers to create and update entries, comments, and either annotate or edit other resources
 (Atom対応のサーバーソフトとクライアントソフトを使って、新規にエントリーの作成や更新、コメントやその他の操作をする事が出来る。)
 *Archiving : Use for internal storage, import, and export of entries, comments, and other resources
 (内部的ストレージ、エントリーなどのインポート、エクスポート)
 *Commenting : Use to post comments to an entry
 (エントリーへのコメントのPOST)
 *Cross-linking : Use to notify one entry about another entry (usually external, similar to TrackBack)
 (相互リンク:TrackBackのようなもの)
 ---

さらに、現在のTrackBackの仕様にある「文字化けの欠陥」が、Atomの使用により根本的に解決する。

参考(
The Atom API
What is ATOM?
Atom as the New XML-Based Web Publishing and Syndication Format.
「Atom - 新しいXMLベースのWeb公開
The Atom Syndication Format (PRE-DRAFT)
Atom Feedの仕様(Preドラフトの段階)
Finally Atom

投稿者 BlogWrite担当 : 22:11 | コメント (0) | トラックバック