Tauri
Tauriは、レンダリングにwryを、ウィンドウ生成にtaoを使っている。 何それonigiri.w2.icon
tauri-pluginていうのはおそらく、fsやdbなどのネイティブで操作すべき機能をjs側に直接提供するための仕組み。
他にも使い方あるのかもしれないが、今のとこ俺にはそう見えてる。
ex）
Tauriのアーキテクチャは、マルチプロセスアーキテクチャであり、「コアプロセス」が中心にいる。
これにより以下の利点が得られる。
セキュリティ：
ビジネスロジックなどはコアプロセス側に寄せることで、重要な情報の漏えいを抑える。
パフォーマンス：
マルチプロセスなので、webviewのUIでハングさせるってことは起きにくい。
並列で計算とかできるし。
ロジックも綺麗になりそうよなonigiri.w2.icon
クライアントとサーバーみたいな組み分けできそうだし。
たとえば、ユーザー入力を常にサニタイズ（無害化）し、フロントエンドでは決して機密情報を処理しないようにし、理想的には、攻撃対象領域を小さく保つために可能な限り多くのビジネス・ロジック（業務処理手順）を「コア・プロセス」に委ねる必要があります。
了解ですonigiri.w2.icon
ビルド方式を調整するオプションがあり、それによってアプリサイズを小さくできたり、バイナリの実行速度を上げれたりする。
webviewとcoreの間での通信は2つある。
1. Event
一方向のイベント型の通信であり、リクエスト/レスポンスという形ではない。
どちらからもメッセージ多くれる。通知として使える。
2. Command
これはリクエスト/レスポンス型。
しかし、webviewからしか始められない。
q.icon 以下のセキュリティ的に安全と言ってるのはなぜなのか
コマンドは、内部ではメッセージ・パッシングを使用しているため、実際の「外部関数インターフェース（FFI）」と同じようなセキュリティ上の落とし穴はありません。
ブラウンフィールド型がdefaultで速度は速いが...
アイソレーション型の方がセキュリティ的に安全（速度は遅くなる）
速度重視じゃない限りは、アイソレーションを使った方がいい。
いまいち理解できなかっった...onigiri.w2.icon
俺にはまだ速い領域かもしらん。いったんStayだ。
q.icon 2つのIPCパターンの理解をより深める
https://scrapbox.io/files/681ce7bd509409ef35636ff7.png
リモートへのリクエストは、webviewから行うのか。なるほど。
でもまぁ確かにそっちの方がいいな。システムや重要情報と繋がることになるCore部分がネットワークと繋がるのは危険だonigiri.w2.icon
Webviewはバンドルに含めない。そうすることで、脆弱性が見つかった時のエンドユーザーへの対応が早くなる。
なるほど。
ここが本丸かもしらん。ここで調整する感じに見える。
これ、capabitiesとは別の何かだな。一緒ではない。