私は「一般的なフィードタイプのための最適化されたウェブフィード集約アプローチ」というタイトルの論文を読んでいて、グーグルのPubSubHubbubプロトコルが議論され、その論文はその欠点を次のように述べました
さらに、フィードリーダーとサーバー間のモデレーターと見なすことができるpubsubhubbub（Google 2010）などのパッチシステムがあります。これらのソリューションはすべて、クライアントとサーバーの両方が拡張機能をサポートしている場合にのみ機能しますが、これはめったにありません。たとえば、Pubsubhubbubは、データセット内のフィードの2％でのみサポートされています。
私は実際にこのプロトコルを操作したことがありませんが、フィードを取得するためにクライアント側（サブスクライバー）にフィードリスナーが必要なように、クライアント（サブスクライバー）がシステムに何らかのソフトウェアを持っている必要がありますか（上記の意味です）？
彼らがその 2% という数字をどこから引き出したのかはわかりませんが、おそらく正しくありません。たとえば、主要なブログ プラットフォームはすべてPubSubHubbub をサポートしています。多くの報道機関 (HuffPo、Gawker、Foxnews、ABCLocal など) もこのプロトコルをサポートしています。Craigslist、Getglue、(さらには StackOverflow) などの他の多くのサービス。Github や Instagram などの他の多くのサービスは、現在の (0.3) 仕様の範囲外ですが、JSON リソース用の PubSubHubbub のような API をサポートしています。リストは延々と続く。
複雑さに関して言えば、大きな利益を得るためにはそれほど難しいことではありません。「クライアント」(技術的にはこれらは Web サーバーです) は、ファイアウォールの外側で可視化され、アクセス可能である必要があります。パブリッシャーにとっては、以前に選択したハブに ping (単純な HTTP POST 要求) を送信するだけでよいため、さらに簡単です。