昨日の記事が予想以上にフィードされているようで、こういう議論が出来ているのをまず嬉しく思います。
もっとも、外で騒いでいるに過ぎないのは確かなのですが、こういう混沌さと真剣さはやっぱり大事なんですよね。
一応言い出しっぺとして、miyagawaさんの記事: [excite Blog の API]に反応しておこうと思います。
概ねこの議論に参加されている方々はmiyagawaさんも含めて(記事でもフォローされているように)ほとんど論点や意見の収束方向に変わりはないように思え、それぞれがそれぞれの記事を読みつつ、納得や理解されているような感じかなと思います。
miyagawaさん記事中のXML-RPCとAtom APIの選択肢に対する考察に関しても、以前ウィザシステムの担当者さんとお話してさせて頂いていたことがあるのですが、私はほぼ同意見です。
miyagawaさんはalternativeな意見とされておられますが、特に私はこれをalternative、少数意見や異論とは感じません。必然的に議論をしていれば単純に出てくる意見でもありますし、論拠もありえます。
ここで指摘されているサービスプロバイダ事情の分析とは、簡単に言ってしまうと既存標準に振り回されるより独自実装の方がコストが安いとの判断が働いたのだろう、との意味と推察します。
# 念のため、文中の「メソッドごとにシグニチャの順番が違っていたりしてかなりうっとうしいことになります。だったら最初からクライアントもサーバも拡張メソッドだけで書いたほうが実装がシンプルになる」の部分がよく理解出来ませんでした。今回の拡張メソッドだとどの程度楽になるかは分かりませんが、XML-RPCを発行してハンドリングする手間は経験則上別に変わらないと思うので。文脈から上記のように理解していますが。
上記に関連して、恐らくtsupoさん記事の
管理画面の html ソースを見たことがある人なら、見覚えがある文字列がいくつかあると思います。 たぶん、管理画面のソース(asp)を元に、XML-RPC API を作ったんでしょう。
という指摘が鋭く思え、内部的には管理画面とフィールド名を合致させてやることで、その後の処理が通常の登録プロセスをそのまま活用できる、といった読みがあったのかも知れませんね。
とすると、miyagawaさんの指摘は非常に現実味があります。
さて、しかしながら(前置き長くてすみません)、これは先の記事でのポイントのつもりなのですが、それでも指摘したいのは、だからこそ何故、実際にシステムに携わるはずの中の人たるエンジニアがそうした安直な方向性へ逃げてしまったんだろうかということです。
私はここに拘っており、サービスプロバイダ側として一括りにしていない、と言えるでしょうか。ひょっとすると、ここがmiyagawaさんから見られた際の違和感がある部分かも知れないし、（そこまで）非難すべきことではないと感じられる差異かも知れません。
「上に言われたから」「コストがなかったから仕方ない」と言われればそれまでですが(もしただ開き直られるだけなら、特に今後これ以上言及するつもりもありませんけど)、単に技術的に無知でやってしまったんなら尚更、上記のような「大人の事情があった」がためなら尚のこと。それが標準 API を実装しないことのデメリットをすでに抱えているのが明白だとしても(しかしながら、晴れて上場企業となったエキサイトが社会における認識度含めて「小人」とは思わないのですが)。
見過して無視をするよりは、議論が出てくる方が明らかに自然だと思いますし、標準無視だと声を上げること「のみ」で非難しすぎ/叩いている、と呼ばれてしまうのはちょっと辛いかな、という気はします。基本的には他の皆さん含めて技術論に徹していると思いますし。
# とは言え、miyagawaさんが提示された視点はこの業界で飯を食っている人間なら必ず陥るジレンマである訳で(こんな納期とコストでやらされたら、何人か首吊るっす・・)、非常によく分かっているつもりではあるんです。
一点、現状では全くこうした事情の真実は何も知らない訳で、今後標準に即した実装が計画されていて正式なアナウンスが出てくるかも知れないのは確かです。
正直に言うと私なんかはかなり軽く考えていて、実は今日あたりエキサイトにメールで軽く聞いてみようかな、などと考えていたのですが、先方にしてみればそんなおおげさに騒いだり見つけたりして欲しくない(例えば今回の対応はやむを得ない一時対応で、とか)のかも知れず、もうしばらく傍観してみようかなと思います。
「しばらく」の定義は難しいですが、いずれにせよ様々な目や声、時間が経てば先入観に変化した視点に晒されることになるのは明白でしょうし、それこそが実質標準プロセスの根底なのでしょうから。
取り留めない文章で失礼しました。
TweetCOM R1.0.0を公開します
![[RDF Site Summary 1.0]](http://www.rocaz.net/pic/feed-icon-orange.png){kind=icon}
![[RDF Site Summary 2.0]](http://www.rocaz.net/pic/feed-icon-red.png){kind=icon}
ニコニコPodder
2009-11
一つだけ,
実は私も「メソッドごとにシグニチャの順番が違っていたりして...」という意味がちょっとわかりませんでした.
もっとも,XML-RPCを直に扱おうとすると,とんでもなく,冗長なため,気が滅入るのは確かです.
だから,XML-RPCを処理するライブラリが増えたのでは、などと邪推したりしてるんですが...^^;
XML-RPC関連はライブラリが非常に充実してますよね。
旅行びと日記ではXML-RPC.NETを使ってるんですが、メソッドのマッピング定義さえすればローカル関数感覚で構造体への返り値処理からExceptionまで完璧にしてくれるのでちょー楽チンなんです。
多分これが無ければ、Blogクライアント対応しようとは思わなかったことでしょう。
Perlその他でもまずライブラリなしで開発は考えられないでしょうね。
こことかに一覧が: http://xmlrpc.scripting.com/directory/1568/implementations
Atom APIもSOAPラッパー前提ならネイティブでもよいのでしょうが、RESTまで考えるとやはり何らかのライブラリに依存したいところです。
以前(.NET前提ですが)探したことはあるんですが、Atomizer (http://www.gotdotnet.com/workspaces/workspace.aspx?id=4cd32ea2-c4be-400e-9391-caf05c0d273a) ぐらいしかこれは、というのは見つけられませんでした。
このあたりも今後の課題でしょうか。
という意味でも、現在執筆中との記事にも期待しています。個人的にはAtomにおける現状での限界点と今後の方向性などの動向情報があるといいなー、と(勝手言ってますが)。
発売されましたら、ぜひ告知頂ければ幸いです。
http://atomnet.sourceforge.net/
正式版になったらもっと出てくると思います。（期待してるだけ＾＾）
＞現状での限界点と今後の方向性
なるべくとりくんでみたいと思います。
これを、読み込ませると勝手にインターフェースとか、クラスとか生成してくれるはずです。
「AtomAPI in WSDL」
http://www.kbcafe.com/iBLOGthere4iM/atom3.1.wsdl
http://www.kbcafe.com/iBLOGthere4iM/AtomApi.0.3.0.wsdl
（Delphiでは上のしか動かなかった...下のが最新らしいです）
「Documented WSDL」
http://www.kbcafe.com/iBLOGthere4iM/?guid=20040614174016
www.atomenabled.orgでもwsdlは以前見つけたことがあったのですが、こちらの方が拡張?されてるみたいですね。
ちょっとVS.NETで試してみましたが、AtomApi.0.3.0.wsdlではアトリビュートの基底タイプがうまく取れないようでした。ぱっと見は問題なさそうではあるんですが。ns指定の問題かな??
でも WSDL and XSD together(http://www.kbcafe.com/iBLOGthere4iM/AtomApi.0.3.1.wsdl) なら問題なく参照化されました。XSDが付いているなら、そちらの方が無難なようですね。
BloggersかTypepadあたりでちょっと遊んでみます。
ニコニコPodderへの質問の際には以下に留意ください
バグや問題点のご報告は常に歓迎しています。また発生した問題の解決にはできるだけ協力させて頂きたいと思っています
皆さんのご理解とご協力をお願いします