開示:私はフェイの作者です。
- フェイに関しては、あなたが言ったことはすべて真実です。
- Faye は Bayeux のほとんどを実装していますが、現時点で欠けているのはサービス チャネルだけです。特に、Faye は Bayeux の CometD 参照実装と互換性を持つように設計されており、これは以下に大きな影響を与えます。
- 概念的には、はい: FayeはSocket.IO を使用できます。実際には、これにはいくつかの障壁があります。
- Socket.IO がどのようなサーバー側サポートを必要とするのか、Faye クライアント (Node と Ruby にはサーバー側クライアントがあることを思い出してください) が任意の Bayeux サーバー (および Fayeサーバーから任意の Bayeux クライアントへ) は契約を破る可能性があります。
- Bayeux には、サーバーとクライアントが特定のトランスポート タイプをサポートするための特定の要件があり、どちらを使用するかをネゴシエートする方法が示されています。また、XHR リクエストの Content-Type がコンテンツの解釈方法にどのように影響するかなど、それらの使用方法も指定します。
- 一部のタイプのエラー処理では、トランスポートに直接アクセスする必要があります。たとえば、Node WebSocket の終了後にクライアントが再接続したときにメッセージを再送信する場合です。
- 間違いがあれば訂正してください - これは Socket.IO のドキュメントをざっとスキャンした結果に基づいています。
- Faye は単なる pub/sub であり、もう少し複雑なプロトコルに基づいており、多くの優れた機能が組み込まれています。
- サーバー側とクライアント側の拡張機能
- チャネル ルートでのワイルドカード パターン マッチング
- WebSocket が停止したり、サーバーがオフラインになった場合などの自動再接続
- クライアントは、すべてのブラウザー、電話、および Node と Ruby のサーバー側で動作します
Faye はおそらく Juggernaut に比べてはるかに複雑に見えます。Juggernaut はより多くの委任を行うためです。たとえば、トランスポート ネゴシエーションを Socket.IO に委任し、メッセージ ルーティングを Redis に委任します。どちらも良い決断ですが、バイユーを使用するという私の決断は、自分自身でより多くの仕事をしなければならないことを意味します。
設計哲学に関して言えば、Faye の最も重要な目標は、Web が利用可能なあらゆる場所で動作し、簡単に操作できるようにすることです。使い始めるのは本当に簡単ですが、その拡張性により、非常に強力な方法でカスタマイズできることを意味します。たとえば、認証拡張機能を追加することで、サーバーからクライアントへのプッシュ サービスに変えることができます (つまり、任意のクライアントがプッシュするのを停止します)。 .
サーバー側でより柔軟にするための作業も進行中です。クラスタリング サポートを追加し、コア pub-sub エンジンをプラグ可能にして、Faye を Redis や AMQP などの別の pub-sub システムのステートレス Web フロントエンドとして使用できるようにすることを検討しています。
これがお役に立てば幸いです。