4

(新しい) Firefox 拡張機能と既存の C# コードとの間の通信を構築する方法について質問があります。

Firefox 拡張機能は構成データを使用し、他のデータを生成するため、どこかから構成データを取得し、その出力をどこかに保存する必要があります。データは既存の C# コードによって生成/消費されるため、拡張機能が C# コードと対話する方法を決定する必要があります。

関連する要因:

  • 比較的管理された企業環境で、Windows 上でのみ実行されます。
  • C#で構築されたマシンで実行されているWindowsサービスがあります。
  • データをローカル データストア (sqlite など) に格納すると、他の理由で役立ちます。
  • データの量は少なく、たとえば数分ごとに 10kb の圧縮されていない xml があり、あまり「おしゃべり」ではありません。
  • データ交換は、完全ではないにしても、大部分が非同期である可能性があります。
  • すべてのプロジェクトと同様に、リソースが限られているため、比較的簡単なオプションが必要です。
  • 超高性能である必要はありませんが、大きなオーバーヘッドを追加するべきではありません。
  • 私はJavaScriptで拡張機能を構築することを計画しています(ただし、本当に必要な場合は別の方法で確信できます)

私が検討しているいくつかのオプション:

  1. XPCOM から .NET/COM へのブリッジを使用する
  2. sqlite db を使用します。拡張機能は、そこから読み取って保存します。C# コードはサービスで実行され、db にデータが入力され、サービスによって作成されたデータが処理されます。
  3. TCP ソケットを使用して、拡張機能とサービスの間で通信します。サービスにローカル データ ストアを管理させます。

(1) に関する私の問題は、これがトリッキーで、それほど簡単ではないと思うことです。しかし、私は完全に間違っている可能性がありますか?(2) で見られる主な問題は、sqlite のロックです。一度に 1 つのプロセスしかデータを書き込めないため、ブロックが発生します。ただし、一般的にはローカル データストアがあると便利なので、パフォーマンスへの影響がそれほど大きくない場合、これは魅力的なオプションです。(3)が特に簡単か難しいかはわかりません...またはプロトコルにどのようなアプローチをとるべきか:カスタムまたはhttp.

これらのアイデアやその他の提案について何かコメントはありますか?

更新: C++ ではなく JavaScript で拡張機能を構築することを計画していました

4

4 に答える 4

3

個人的には、ソケットの代わりに名前付きパイプを使用して通信を行いました。オーバーヘッドが非常に低く、Windows での信頼性が非常に高いです。

これは、C++ および C# から非常に簡単に使用できます。

于 2009-11-21T01:08:50.670 に答える
1
  1. 何らかの種類の RPC が必要な場合は、最初のものを使用してください。そうしないと、RPC 言語、バリデーション、構築/分解などを作成することになり、ローカル マシンで何かを行うには少しやり過ぎになってしまいます。

  2. 非常にパッシブなプラグインを使用している場合に最適なオプションです。3 番目のコンポーネントは 2 つのプロセスを完全に分離します。これは、前述のように、非同期、テスト、実装の容易さなど、多くの点で優れています。多くのメッセージ パッシングを行いたい場合は、おそらくばかげた考えです。

  3. おそらく、ほとんどの場合、全体的に最適なオプションです。TCP/IP は、インターネット経由でデータを送信するという観点からは優れていますが、実際には 2 つの異なる IP アドレスを使用したり、Web サーバーの設定やポートの競合の可能性をいじったりする必要はありません。パイプの方が理にかなっていますが、他の同様のシリアル通信モデルもあります。それはうまく分離し、完全に非同期にすることができ (TCP/IP は非同期であり、通常の HTTP はそうではなく、パイプも同様です)、テストが非常に簡単です (もちろん、プロトコルを記述する必要がないことを前提としています)。コードベースについてはあまり気にしませんでした。つまり、明日、C# バックエンドが Ruby や Python に変わったとしても、すべてが「問題なく機能する」ということです。ライブラリとデータベース全体をプラグインでパッケージ化することを心配する必要がないため、sqlite よりも優れています。

3 番目のオプションの唯一の欠点は、(1) 物事が非同期になるが、応答性とアクティブ性が必要であることです。一方、sqlite では物事がほとんど受動的であるだけでなく、コンピューターを 1 週間シャットダウンしても段階的になりません。 . (2) RPC にとっても驚くべきことではありません。もう一度やりたい場合は、独自のプロトコルを発明するか、SOAP や WSDL などを処理することになります。

于 2013-07-07T18:13:17.253 に答える
0

私が選択したオプションは #2 でした: sqlite db を使用します。主な利点は次のとおりです。

  • JavaScriptで実装可能
  • 他の理由で役立つsqlite dbの使用
  • 非同期通信によりパフォーマンスが向上します。C# コードは、Firefox 拡張機能が必要とするすべての情報をオンデマンドで準備するのではなく、キャッシュすることができます。FF 拡張機能は、すべてのデータを C# コードですぐに処理する必要なく、sqlite db に保存することができます。
  • 別のレイヤーは優れたテスト ポイントを提供します。たとえば、FF と C# で動作するテスト ハーネスを必要とする代わりに、FF コードのみを実行し、期待される結果を sqlite で検証することができます。

これらのいくつかは明らかにシナリオに依存するため、これが FF extn と C# サービス間の通信に最適な汎用オプションであるとは断言できません。

更新: 最初は sqlite db のみを使用しましたが、同期通信が必要だったので、後で FF 拡張機能によって呼び出される C# Windows サービスから http Web サービスを公開しました。この Web サービスは、FF 拡張機能と他のブラウザー拡張機能の両方で使用されるようになりました。さまざまな言語のさまざまなアプリで簡単に使用できるため、Web サービスであることは素晴らしいことです。

于 2010-05-01T21:43:59.417 に答える
0

JavaScript を使用する場合、C++ でプロキシ コンポーネントを記述して OS API に直接アクセスできるようにする以外に、名前付きパイプやその他のシステム依存通信を使用する別の方法はないと思います。一方、IPC に TCP/UDP を使用する場合は、Firefox が JavaScript コンポーネントから簡単に使用できるソケット サービスを提供するため、はるかに簡単になります。

ブロッキングが懸念される場合は、非同期ソケット通信またはスレッド サービスを使用して Firefox の GUI のロックを回避できますが、多くのオブジェクトは Firefox のメイン スレッドからのみアクセスできることに注意してください。

于 2009-11-21T21:57:21.207 に答える