RSS は PUSH か PULL か

だいたい書いてあることは自明なので同意するわけですが、スケールしないのは明らかなのになぜこんなナイーブな技術を推進するのか、という疑問にはどう応えますか？

クライアントが手元のアプリケーションで収集する、クライアントがリモートのWebアプリケーションを利用する、リモートにRSSをアグリゲートするサーバーを配してクライアントアプリケーションからそれを利用する、いずれのモデルを考えてもクライアント数やRSSの個数の増大とともにレスポンス時間(ターンアラウンド)が増大したり、アクセスが集中したりすることが避けられません。それがたまたま現在Acceptableな範囲に留まっているというだけではありませんか？

普通にCSのセンスのある人だとそう感じるように思います。アクセスを局所化する仕組みと一緒に提案しないと意味がないと私などは思ってしまいます。論文なら落とします。

うーん、なるほど。確かに現状 Acceptable な範囲に収まっているから ok であり、みたいなところはご指摘の通りかもしれません。

ただ、スケーラブルな仕組みにしてもなんにしてもそうですが、それがスケールしないという認識が生まれてそこに解決策を見出して発展していくという方向でも間違いではないのかなと思います。

例えば Bloglines が API を公開してキャッシュ技術によりそういった解決策の提案を為しているところとかもそのひとつですよね。

トップダウンで仕様によりスケーラブルな仕組みを提案するという方向性と、現状の仕様を ad hoc に利用するという方向性と、その二つが同時に進んで新たな局面を迎えていくという進み方が現実的ではないかなと思っています。

Blog のトラックバックもそうですし、HTML のいいところ悪いところもそうですが、決して仕様がそのニーズのすべてを埋めているわけではなくても、新しい可能性の実装としてそれが世に広まり、その運用を行っていくうえで新しい課題がみつかり、それを解決するためにスケーラブルな方針が打ち出されていく、という、変化に対応していく上での進化というのが、結果として仕様をブラッシュアップしていく...という考え方でお茶を濁してしまってはまずいかな?

感想：

[1] ((o)さん)は、良く研究者っぽい人が使う論理ですね。確に「新しくない」とか「論文なら落とす」とか、あるいは具体的には「スケールしない」とかいうのは、その通りなのですが、別に論文的な意味で新しいと主張している人はそんなにいないと思いますし、だいたい、論文じゃないからよいのでは、という気がします:-)

[2] naoyaさんはビジネス最先端の方だと思うのですが、思いのほか温厚？なご意見で(極端だが二つに一つで選べと言われれば、需要の無いところに投資はあり得ないので答えは自明、くらいの表現がくるかと思いました:-)、一利用者である私とほぼ同じようにおもいました。

一利用者である私は、何はともあれRSSのコンテンツが増えてうれしい、今後トラフィック増加が問題になりそうなら、RSSのpushなりp2p配信なり考えてください、という感じです:-)

遠目にみれば、どの立場も実際はそんなに異なるわけではないと思っているのですが、どうも解離しているような雰囲気がこの業界?にある気がするのは私だけでしょうか?

PUSH/PULLという言葉が流行したのはだいぶ昔になりましたが，その頃はこんな区別でした。これ言い出したのはMSかな？

-PULL : クライアントが取得しに行く
-Smart PULL : クライアントがクライアントの都合で定期的に取得しに行く
-PUSH : 取得タイミングが取得される情報側に記述されていて，その情報を元にクライアントが定期的に取得しに行く

なのでRSSをPUSHといってもそれほど変じゃないかも知れない。

RSSは次の取得タイミングを教えてくれないので同期メッセージとして機能しないのでは。やはりPUSHだというのは少々厳しいように思いますね。
両者には満たせる時間制約に差があるのでしょう。けれども、「アプリケーション」が要求する制約がマイルドなときにはPULLでも問題ないし、前述べたスケーラビリティも時間制約がマイルドならば問題とはならないと、こういうことなんですよね。
私個人はBloglinesの速報性には満足していませんけれどね。

少し古い記事ですが、コメントの流れに合うと思いますので。

Windchase: Microsoft blogの事件にみる，RSSのスケーラビリティの問題
http://artension.jp/blog/archives/2004/09/14_000027.html

一応「対岸で一度火事が起きたぐらいの状況」とは言ってもいいのかも知れません。

あと本題とは関係ありませんが、とおりがかりさんの「どうも解離しているような雰囲気」は、この辺の分野が、学問としての情報工学、工業としての情報工学、ビジネスとしての情報工学という３層が、他の分野に比べ比較的幅の狭いところにあるために感じられる事ではないかと思います。（単語に違和感があれば適当に英訳したりして下さい（笑））
でも、同じとまでは言いませんが、似たようなすれ違いから出てくる乖離や温度差はそこかしこで見られるように思います。
ほら、営業と技術とか、管理職と現場とか、世代論とか =)

>>5 (o) さん

> RSSは次の取得タイミングを教えてくれないので同期メッセージとして機能しないのでは。やはりPUSHだというのは少々厳しいように思いますね。

ここにだけ反応。

このエントリで僕がいわんとしてることは「RSSはPUSH技術だ」っていうことではなくって、RSS は実際には PULL 技術なんだけど、(技術に明るくないひと、言うなればエンドユーザー)からみたら、かつて PUSH 技術がめざした広告配信システムとかそういうものと同じようにアプリケーションが動くので、PUSH 技術として捉えるんだろうな、ということです。

> おそらく、技術指向な人は PULL だと受け取りそうじゃない人は PUSH だと受け取るのではないかと思います。

のくだりです。

再び、とおりがかりのものです。

>>6 TKS さん

> 一応「対岸で一度火事が起きたぐらいの状況」とは言ってもいいのかも知れ
> ません。

確に人気サイトでは結構きつくなりつつあるのかも知れませんね。asahi.com
とかは本文は最初から無かったと記憶していますが、それで、そこまでの問題
にはなっていないのでしょうか…。まあ、広告との絡みもあるので、単にいれ
ないだけかもしれません。

> あと本題とは関係ありませんが、とおりがかりさんの「どうも解離している
> ような雰囲気」は、この辺の分野が、学問としての情報工学、工業としての
> 情報工学、ビジネスとしての情報工学という３層が、他の分野に比べ比較的
> 幅の狭いところにあるために感じられる事ではないかと思います。

これも単語の語感はともかく:-)まったく同感です。「解離しているような雰
囲気」と書いたのは、googleのようなものをイメージしながら、逆に解離しな
い状態ならすごくうまくいくようなものがもしかしたら出来るかもしれない、
そうなるといいなぁ(せっかく他の分野に比べて「近い」んだし)、というよう
な希望的観測を込めた、というニュアンスもあるつもりでした。

>> 5 で (o) さんがいうように時間制約の厳しいものは、いまのRSSではイマ
イチなのは当然です。ただ、ファイヤウォールの問題とか、既存の枠組みをう
まく利用できることを考えれば、当面いまの形態のRSSのほうが利点がずっと
多いでしょう。逆に、純粋なPUSH的な仕組みを広めようと思えば、今のRSSの
利用者/情報提供者が増え、スケーラビリティや即時性の問題が解決されて欲
しいなぁ…と思う人が増えない限り、論文は書けたって、それで終りです。ス
ケーラビリティは利用者が少なければまあよいですが、即時性のほうは個人的
には「今は我慢するけど将来は何とかして欲しい」と思っているので、そのた
めにもRSSのような「プチ即時性情報配信」というか「なんちゃってPUSH」が
それなりに広まって欲しい、というのが私の考えです。個人的には、分の精度
になったら、交通情報とか電車の運行状況とか新聞の号外みたいなものが、秒
まで来たら：

http://www.atmarkit.co.jp/news/200501/15/apexera.html

こんなのまで出来るといいなぁ、と思っていますが、はてさて。

この話、悩ましいと思います。仕方なく「擬似的プッシュ」とか言っています。

トピ主の意図をないがしろにしてごめんなさいね。もちろんPULLベースのシステムでPUSHライクなユーザビリティを実現する非常に面白いアプリケーションだと思っていますよ。ただ、「RSSリーダーはメールクライアントっぽいインタフェースがしっくり来るなあ」という感想が書かれているブログが散見されるに至って、技術の普及が進むことを実感する一方、本来PUSHっぽいユーザビリティをスポイルする方向も少し見られるのかなというのが私の素直な感想です。

さてさてファイアウォール云々の話は末端インタフェースとしてGET型のものを使えればよいというだけで、それ以外のものを使うならWebでやる意味がないし、Mobile IPやDynamic DNSを繰り返したいわけでもないです。通りすがりの人は論文、論文というのを繰り返しているけれど(最初に言った私が一番悪いのだけど)、そもそも論文では実装技術に新規性なんか求めません。時々新規性を主張している論文も見ますが真に新規性と呼べるものなど皆無です。要は合理的な目標を設定してそれに合理的な手段を採ること、合理性の証明をすることが求められているだけです。つまり、(大学でどういう教え方をしてるのかは知りませんが)CSは立派にエンジニアリングですよ。ついでに言うと、ニーズを増やすというのはもちろんその価値は私も大いに理解するところで、実生活では技術シーズを生み出すのとビジネスに展開するのを両方やらされていて大いに苦労させられているわけです。

なんだけれども、一方で技術シーズをいつまでもこのままの状態に放置し続けてもなーとも思うわけです。幸い乖離(?)の程度が小さいためにスケーラビリティと速報性という問題の共有は迅速にできたし、合理的な目標を立てるのもできるでしょう。地震の速報システムなんか面白いじゃないですか。で、どうするかですよ、やはり。