ブラウザとその他のプログラムとの連携について

[YoshihiroOota]

弊社の海外部署に HTML5 と推奨している有償ブラウザの紹介を行ったところ、海外で販売活動を行うに辺りアプリケーションの実装について教えて欲しいと質問を受けましたので、ご存知のことがありましたらご教示いただけないでしょうか。 ブラウザアプリの構成の概要を教えてほしい、とのことなのですが、具体的にはブラウザアプリケーションに、その他のプログラムをどのように組み込んだら良いかという問い合わせとなります。 ブラウザ外で動作している箇所 (H/W にアクセスする必要があるモジュールや、C/C++で記述されたアプリケーション)をどのように設計してブラウザ上の Javascript と結合したり、これらの機能を別個のOSプロセスとしてインプリしてブラウザとプロセス間通信する方法などが知りたいようです。当方の解釈誤りがあると質問がブレるので、英文も合わせて記載いたします。 (原文) More specifically, how did they integrate the parts of their application cannot run in the browser, e.g. modules that need to access the hardware, or are written in C/C++, etc.? E.g. did they somehow do that in Javascript that runs in the web browser, or did they implement their functionality as a separate OS process and used some IPC mechanism to talk to it from the web browser?

もう少し紐解いて、実際にお客様が想定しているユースケースを絞らないと最適な方法は検討できないと思いますが、一般的に使われている手法などがありましたら、ご紹介いただけると助かります。

[YoshihiroOota]

その他のプログラムが何で実装されているかも重要そうですが、node.js を使用した WebSocket による通信が良いのでしょうか。以前、デモを作成いただき速度を測定したと思います。

[YoshihiroOota]

他に、弊社で試した方法として、python で外部デバイスを制御する Webアプリを作成し、HTTPのリクエストとレスポンス(?)で通信、ブラウザ側で取得したデータに合わせてグラフ描画を試したことがありますが、これは質問事項に対する内容とは違う気がします・・・。

[YoshihiroOota]

Mozilla の推奨としては、こちらになるのでしょうか。 https://developer.mozilla.org/ja/docs/Mozilla/Add-ons/WebExtensions/Native_messaging

[dynamis]

概ね既に太田様の把握されている通りです (Native Messaging を推奨と言うことは特にありませんが)

一般論としてはどちらかを相手に合わせる必要があり、個別各論としてはネイティブモジュール側の規模・通信量・ソースの開示が可能か、既存資産の再利用性、要求パフォーマンスなどに応じて適切な手段を選択します。Web とネイティブ橋渡し自体はどちらに合わせるかとその時の通信方式によって

• A. ブラウザ側をネイティブモジュールに通信可能にする
  • Native messaging, JS API の独自拡張 (Gecko 自体を改変)
• B. ネイティブモジュール側を Web コンテンツから通信可能にする
  • ローカルサーバと WebSocket, HTTP, WebRTC などで通信

いずれかで、ハード制御自体への通信は限られるがネイティブモジュールへの通信量が多すぎる場合だと既存のネイティブモジュール側のコードを WebAssembly (が無理なら JS) に移植した上で、ハード制御部分だけをネイティブに残すといった、モジュールの境界線を変更する対応もあり得ます。

具体的にどのような設計にして、どの通信方式を用いるかは個別案件に対して検討が必要ですが、ある程度典型的なパターンについてはサンプルと解説を用意しなければメーカー側としては悩ましいところかと思います。

[dynamis]

More specifically, how did they integrate the parts of their application cannot run in the browser, e.g. modules that need to access the hardware, or are written in C/C++, etc.? E.g. did they somehow do that in Javascript that runs in the web browser, or did they implement their functionality as a separate OS process and used some IPC mechanism to talk to it from the web browser?

It depends. It depends on your native modules. If the module need to control hardware (unless the hardware can be accessed via existing web apis like WebRTC for audio/video or WebAuthn for Yubikey etc) you need to select some method and protocol to communicate with:

A. Make web content accessible to the native module with

• Native messaging (web extension api), JS API enhancement
  • Native messaging is supported by Firefox by default and easy to use it (note: we haven't verified if it actually work well on RZ/G since extension support is out of the scope of our verifications) but need to communicate via background JS and overheads become larger. So use this only if you can accept the overhead
  • JS API enhancement require your own patch for Gecko but best for performance and flexibility of course B. Make native module accessible from the web content with
• WebSocket, HTTP, WebRTC etc server on localhost
  • websocket server is the simplest and most famous way for this. You can use any websocket module of node, python, C and many other language implementations
  • HTTP server is also obvious alternative and you need not implement/use full featured http server, if you just need to get signal from web content sometimes, this may be the option
  • WebRTC can also be used but I don't recommend this for almost cases since it use encryption even for communication to the localhost and overhead become larger

In case your module is written in C, C++ etc but it will not use specific hardware, another option is to compile native code to WebAssembly (or JS). WebAssembly is in general slower than native C module but difference is not so large and it became better than communicating with native module in the separate process.

So, you need to consider your module or product's architecture, performance, volume or frequency of the communication etc. If you cannot judge it, you need request help for consultant.

[dynamis]

note: native messaging は拡張機能 API であり Gecko の HTML エンジンの機能ではなく Firefox ブラウザの拡張機能サポートの一環として提供されているものであり、少なくとも今のところは RZ/G の VLP で verify する範囲の API ではありません。

とはいえ仕様が明確でドキュメントやサンプルも多い API が使えるのは便利なので確認したりガイドラインを用意しておくことはメーカー側からの要望としては想定されます。詳細は #80 にて

[dynamis]

QA としては一段落していると思うのでクローズします。 追加情報など必要であれば reopen または別 issue お願いします。