1) プラグインを設計する際に焦点を当てる必要があるさまざまな側面は何ですか?
特定の要件を知っているのはあなただけです。それは、使用するプラグイン テクノロジ/フレームワークに依存します。すべての可能性を処理すると、投稿ではなく本になります。
2) QtBrowserPlugin/NPAPI/XUL/firebreath から利用できる最適なプラットフォーム/フレームワークは何ですか?またその理由は何ですか?
いつものように、最高のテクノロジーは 1 つではありません。
- XUL - これはプラグイン技術ではありません。
- プレーンなNPAPI と ActiveX - これらは、他のソリューションがあなたを救う基本的な基礎となるテクニックです。それらまたは非常に具体的なニーズに合わせて開発した経験がない限り、私はそれをしません。他のオプションが適している場合、特にクロスプラットフォームに移行する必要がある場合は、ここで時間を無駄にしません.
- QtBrowserPlugin - 既に Qt を使用している場合は、それが適しているはずです。それ以外の場合は、Qt が非常に重い依存関係であると考えてください。Qts ライセンスが適切でない可能性があります (LGPL または商用)。
- FireBreath - かなり軽量でリベラルなライセンス (デュアル新しい BSD/LPGL)。ビルドシステムは、すべての開発チームに適しているわけではありません。共同所有者として、私は偏見があるかもしれません。
3) プラグインのライフサイクル中に発生する可能性のある一般的/一般的な問題は何ですか?
ライフサイクルから多くの混乱が生じているようです。プラグインはホスト プロセスに存在し、その動作に準拠する必要があります。プラグイン インスタンス、それらのウィンドウ、およびそれらのスクリプト可能オブジェクトは、完全に異なる寿命を持つことができます:
プラグイン インスタンスは再利用される可能性があり、それらのウィンドウは再利用されない可能性があり、プラグイン インスタンスからのスクリプト可能オブジェクトは存続する可能性があります。
4) この点に関するクックブック/ポインターを教えてください
考えられるすべてのテクノロジーを選択できるわけではありません。1 つ選んでから、より具体的な質問をしてください。プレーンな NPAPI と ActiveX を使用して自分でプラグインを完全に実装する場合は、少なくとも FireBreath のソースがいくつかの点を明確にするのに役立ちます。