Design: WebAssemblyは、Open Web Platformとの互換性を非常に重要と見なす必要がありますか？

私は書かれた声明に広く同意しますが、それに対するいかなる種類の正式なコミットメントも、あなたがリンクした多くの意見の相違を回避したとは思いません。 特に、あなたの声明は、主に提案の採用に対する追加の障壁として表現されていますが、リンクされた問題の多くでは、コア言語への追加を提唱しています。

「機能がWebとの互換性を支援する場合は、それをWasmに追加する必要がある」という架空の極端な位置を検討することは、有用な思考実験になる可能性があります。 JS固有のフック。 私はあなたがそのような立場を支持していることを意味しているわけではありませんが、OPに書かれているあなたの声明はあなたがリンクした問題で出てくるように見える概念的な不一致を捉えていないと思います。

また、コア言語である「WebAssembly」（「Open Web Platform」との互換性を維持する必要があると私は感じています）と、ツール、ホストインターフェイス、およびインポート名前空間のエコシステム（標準化/エンジニアリング）との違いもあります。 。 WASIは、ホストが提供しないことを選択できるインポート名前空間であるため、「Webフレンドリー」であり続けることはそれほど重要ではありません。 最悪の場合、誰かが後でよりWebフレンドリーなAPIを標準化した場合、重複した作業/ツールチェーンの分割が発生します。

ええ、これらの問題のいくつかは少し古い側にあります、そして私は確かに今日それらに異なったアプローチをします（そのようなコミットメントがその時に存在していたならさらにそうです）。 これとあなたの他のポイントについて少し考えます:)

多くの問題でコア言語への追加を提唱しているという印象に少し驚いたので、コンテキストを与えるのは良いことかもしれません。 時折、私は実際にバックポケットの代替案を考案しました（私は推測します）、それは私が思う追加を提唱していると見ることができる議論の文脈で役立つように見えました、特に私がインターフェース間の認識されたデッドロックを解決するのを助けようとしたユニバーサルストリング私の懸念に責任があるとお互いを指し示していたタイプとGC。 後から考えると、GCがより適切な場所であると思われるため、ITの問題でこれを再び取り上げたことを後悔しています。 それはまだそこに爆発したかもしれません、そして、確かではありません。 結局のところ、私はこれらを提案したことはなく、既存の緊張も考慮しましたが、ほとんどの場合、私が具体的に何を意味するのかを説明したいという願望から作成しました。 後から考えると、緊張のせいで何かを提案するのは運命にあるようで、私の議論をより詳細に解決することもできるので、私が自分自身を見つけているのは少しジレンマです。 WebAssemblyの目標をより明確にし、一般的な意見の不一致の解決に取り組んでいることを感謝します。

レガシーJS機能があることも主張するので、仮想の極端な位置は非常に興味深いものです。Wasmは積極的に、またはおそらくまったく心配する必要はないかもしれませんが、それでもどこかに線を引く必要があります。 私の直感では、たとえば、互換性が非常に重要であるため、1つの機能が多すぎる方が少なすぎるよりも優れていることがわかります。 コミットメントが整っていれば、少なくとも少数派が関心を持っている機能について、より少ない摩擦で議論でき、より高い目標を達成するための成功の可能性が高くなる可能性が高くなりますか？

コア言語とより広いエコシステムの違いも同様に興味深いものです。 可能であれば、将来の生態系の問題や非互換性の道をたどらないようにし、たとえば、Wasm ontheWebとWasmofftheWebの間の断片化を回避することについてもっと話し合うべきだと私は主張します。今日の時点ではほとんど存在しないトピック。 たとえば、Node.jsエコシステムでは、非Web用に発明されたすべてのカスタムAPIは最初はクールでしたが、必須のポリフィルよりもWeb APIに固執する（再利用する）方が一般的に望ましいため、今日でも負担になっています。 言うまでもなく、Node.jsでの2回目の試みであるDenoはそれを認識しましたが、より広範なエコシステムは現在、長い間それに固執しています。

重複した努力を避けることがどれだけの価値があるかわかりません。 おそらく回避できる断片化パスをたどらない限り、オプションとしてそれを持っていると便利ですか？ たとえば、WASIはすでにWebAssembly傘下の準標準であり、現在Web上のWasmに忍び込んでおり、成熟するにつれて、プロセスで発見したエコシステムの問題を修正するのが難しくなるため、これを防ぐメカニズムがあります。手遅れになる前の結果は有用なようです。

基本的にWasmは多くのエコシステム、ユースケース、言語に対応しており、常にある程度の妥協が必要になるため、Wasmが特定のエコシステムまたはユースケースに最適でなければならないという絶対的な目標を設定することはできません。

Webと非Webに加えて、これまでのWasmの設計では、Webに幅広い言語セットを導入することに重点が置かれています。これらの言語は、JSの既存の機能を最も補完するため、JSとはほとんど意図的に異なる言語であることがよくあります。 、したがって、JS+Wasmの組み合わせが最も強力になります。 また、既存のソフトウェアのほとんどをWebに取り込むことができ、Webが新しいレベルのパフォーマンスに到達できるようになります。 代わりに、WasmがJSと非常によく似た言語を優先するように設計されていたとしたら、それはまったく無意味だったでしょう。

これは良いことですが、当然のことながら、メモリ管理や文字列などの実装の詳細に関しては、これらの言語はかなり異なる可能性があり、特にこれらの言語を使用する目的は次のとおりであるため、それらのニーズを考慮する必要があります。この新しいコンテキストで効率的になるようにします。 境界での相互運用に関しては、JSとの相互運用だけでなく、複数のWasm言語間の相互運用、そして将来的には、これらの言語とブラウザーや他のWasmホストのネイティブコードとの相互運用も考慮する必要があります。多くの場合、同じまたは類似の言語です。 インターフェイスタイプのような提案は、これらの要件の1つだけでなく、これらすべてのバランスをとろうとします。

話をするのに良いかもしれない別の誤解があると思います。 私は確かに私のプロジェクトのニーズを検討することを提唱してきましたが、最初はそのややユニークな視点（今日のAssemblyScriptの問題のいくつかはWebAssemblyの明日の問題のカナリアであると信じています）がCGにとって価値があることを望んでいましたが、最近では特に今日、私は特定の言語を提唱していませんが、グループ間の不一致を解決する機会をうまく利用しながら、Webでの互換性というより高い目標を提唱しています。 あなたと同じように、Wasmは特定の言語を支持するべきではないと強く信じています。また、特定の言語に賛成または反対することよりもWeb標準間の互換性など、より重要な側面を見失い、議論が行われる可能性が非常に高いことを恐れています。熱くなりすぎて建設的ではなくなり、WebAssemblyの進化が停滞します。 例を挙げると、コメントの言い方を少し不快に思います。これは、私の議題に含まれている可能性があるがそうではないことをかなり多く示唆していると感じているためです。特定の言語、JSの既存の機能を補完し、すべての要件のバランスを取り、必要に応じて妥協し、新しいレベルのパフォーマンスに到達するように努めます。ただし、Web標準がWeb標準ではなくなった場合は次のようになります。非常に残念です。

まず、CGに敵対者がいるという経験は、プロセスの失敗の兆候だと思います。 技術的な詳細や優先順位について互いに強く意見が一致しない場合でも、非敵対的に取り組むことは不合理な目標ではありません。

第二に、JSとの相互運用性がCoreWebAssemblyの成功にとって重要であることに同意します。 これには、まだJS APIを完全に具体化していないが、標準化される前に、GCやEHなどの提案が含まれます。 スタックサブグループもあり、JS相互運用機能を最初のビジネス事項と見なしています。 また、そのステートメントには、コアWebAssemblyの上に、場合によっては個別の仕様を介して階層化されているが、Webプラットフォームに統合されることを意図したITなどの他の提案も含めます。

計算は、Core WebAssembly仕様の非Webコンシューマー、特にWASIでは異なると思います。 CGは、Core WebAssemblyがWebプラットフォームを超えて使用または埋め込まれる方法を制御しようとすべきではないと思います。また、WASIサブグループは現在Webプラットフォームへの変更を提案していないため、私はしません。 Web互換性の義務でそれを妨げることは理にかなっていると思います。 WASIサブグループは、他の標準化団体でも同じ目標を持って常に同じ作業を行うことができると考えてください。ただし、コラボレーション、アイデアの相互受粉、および組織のオーバーヘッド（互換性は言うまでもありません）の点で、私たちは皆はるかに優れています。 ）それはCGのサブグループだからです。

微積分と言えば、「サブグループが悪意を持ってコアWebAssemblyに影響を与えたり、より高い目標を回避したりする場合はどうなるか」という架空の極端なシナリオもここでも興味深いかもしれません。サブグループはWASIですが、同じグループによって効果的に推進されるコア提案であるインターフェイスタイプ機能の包含または除外は、WASIのニーズを非常に簡単に優先することができるため、意識を高めたいと思います。 -他の人のニーズを超えたWeb特定言語サブグループ。 OPの観点からは、すでに後者を目撃している可能性があるため、特にサブグループの取り組みが他の方法で調整されている場合は、リスクに注意して予防策を講じることは必ずしも悪いことではないと主張します。大多数の利益のために、コアWebAssembly、より広いエコシステム、またはさらに悪いWeb標準に損害が与えられる前に、副作用を実現するのは難しいかもしれません。 言い換えれば、WebAssembly傘下のサブグループであるということは、コアWebAssemblyとそのより高い目標に対する責任を意味するはずだと思います。

仮にでも、さまざまなグループに悪意を与えることについてもう少し保守的になるのは良いことだと思います;）

これらの論争の的となる問題の多くは、特にIT提案では、多くの人が密接にフォローしているわけではなく、ほんの一握りの人々に関係し、見られています。 視認性の高い設計の問題については、CGの多かれ少なかれ代表的なサブセットが設計プロセスに関与しているか、少なくとも異議を唱えずにフォローしているため、CGの大部分が反対であるという決定に達することは困難です。 ただし、ニッチな問題については、完全なCGが不快であるという決定に数人の人々の間で到達することは可能です。 このような場合、CGミーティングで特定の問題を提起し、提案された方向性についてCGの全体像を把握することが役立つ場合があります。

この最近の例の1つは、 @lukewagnerが重複インポートを禁止する問題を提起したときです。 あなたが経験したように、CGはモジュールをリンクする人々が思いついた方向に完全に満足していませんでした、そしてその結果、その議論へのより広い参加があり、コンセンサスは別の方向にシフトしました。

最終的に、CGが快適ではない提案は、CGによって進められません。 もちろん、初期の問題が表面化され、議論されているほど、より良いです。 CGミーティングで問題を特定するときに、誰もが問題を提起できるようになることを願っています。

これを何よりもまず述べる-WebAssemblyの採用には、Webプラットフォームとの相互運用性が重要であると思います。互換性については、大まかに同意します。 とはいえ、提案に参入障壁を追加することが前向きな結果につながるかどうかはわかりません。 WebAssembly CGはコミュニティの人々で構成されており、標準を積極的に前進させることに貢献しながら、全員が異なる目標を持つことができます。 異なる目標を持つことは時々摩擦につながる可能性があります、そして私はこれが異なる目標に向かって取り組むときに私たちが敬意を表して反対することができる場所であることを望んでいます。

よりCGレベルのフォーラムの前に、WebAssemblyの一般的な方向性に関して次の懸念事項を検討することをお勧めします。これは、コミュニティとしての私たちが最終的に問題を解決できることを願って、現在フォローしているアドバイスです。

ご存知かもしれませんが、WebAssemblyの目標に対する私の見方は、さまざまな提案を担当する特定のグループのアイデアとかなり長い間衝突しており、多くの場合、多かれ少なかれ白熱した議論につながっています。 ですから、ここには不一致の根源を特定して解決する機会があると思います。そうすれば、最終的には再び共通の目標に向けて調整することができます。 私は自分の視点からしか話すことができません。これは、WebでWebAssemblyを実行することに関心のある人々の間でより一般的であり、Web以外でも、偶然にも私が取り組んでいることであり、他の人の考えに非常に興味があります。

私の見解では、この不一致は、WebAssemblyをOpen Web Platformの一部として最初に宣伝し続けていることによって引き起こされた期待から生じています（以下では「Web」と略します）。 たとえば、WasmはJavaScriptを置き換える（または害を与える）ことを意図したものではなく、むしろコンパニオンテクノロジーであると何度も表明されてきたため、優れた互換性（私にとっては相互運用性）を実現することが優先事項であると常に考えていました。 ）既存のWebを使用します。これは、Web上で一般的に望ましい目標です。 または、webassembly.orgが述べているように：

残念ながら、これらすべての白熱した議論の過程で、WebAssemblyの目標についての私の理解は、CG内のより影響力のある敵が取り組んでいるものと一致していないという印象を受けました。これは、新しいステータスを作成する試みと見なさざるを得ません。これは主にWebとの互換性を考慮に入れています。 この不一致が示した最初の問題は、インターフェイスタイプでのUTF-16LEのSTRING i32ペアです（2017年、Host Bindingsという名前の作成時）。1年半の沈黙の後、UTFかどうかについて多くの議論が交わされました。 -8、Web APIおよびJavaScriptとほとんど互換性のない文字列エンコーディングは、実際にサポートされている唯一のエンコーディングである必要があります。または、最初から互換性も考慮することが役立つかどうかです。 私の本ではこれは当然のことであるはずなので、私は反対の議論の純粋な連鎖に非常に驚いていました。 この問題は最終的に（ほとんど）JavaScriptのような文字列エンコーディングを使用する言語が非常に多く、それをサポートする必要があることを認めることで解決しました。これにより、アダプターフュージョンの完全な概念が生まれましたが、との互換性はほとんど認められていませんでした。特にWebAPIは重要です。 この問題に関連して話すべき非技術的なポイントは確かにもっとありますが、今のところこれらを避け、WebAssemblyの方向性に焦点を当てることをお勧めします。

もう1つの同様の問題は、文字列のGCストーリーですか？ これまでのところ解決には至っていないGCの提案で終わりました。また、目標がMVPである場合は、必ずしもそうする必要はありません。 それでも、これまでの議論では、最終的に解決しなければならない不一致があることも示されました。つまり、WebAssemblyと文字列を含むWeb APIとの間の相互運用性を必要とする方法でGCが使用されるとすぐに、おそらく任意のモジュールグラフも含まれます。理想的には、最小限の変換とコピーで。 一般的な意見の不一致は、アレイのより良いGCストーリーに関するフォローアップの問題にも示されていますか？ 、それは、目前の懸念について議論する代わりに、私の能力と私が取り組んでいるプロジェクトの価値を疑問視するためにすぐに脇道に追いやられました。 どちらかといえば、ここで再び共通点に合わせる機会があることを強調しています。

また、重複輸入を禁止する最近の取り組みにも驚いていましたか？ 、複数の署名によるオーバーロードが一般的であるJavaScriptなどの動的言語と統合するのに役立つメカニズム。 プレゼンテーションの後、同じ会議で削除に投票することを急いで、少なくとも眉をひそめましたが、これは別の誤解、またはプロセスがどのように機能するかについての意見の相違である可能性があります。

誰にも話さないが、問題に投票することは、コミュニティの意見を評価するプロセスの歴史的に有用な部分であり、私は投票するための急いで、より多くの方向性のための投票としてそれを読みません。 ノートを見ると、CGはこの問題にもっと目を向ける必要があると判断し、デザインの問題は引き続きその議論の場となっています。

同様に、私は最近、 WASIがWeb上のWasmのユースケースに害を及ぼす可能性があるかどうかを疑問視するようになりました。 、私に関しては、コミュニティのよりWebに焦点を当てた部分が、関連する提案が遠くないために、断片化よりもWebとの互換性を促進するソリューションを見つける機会を得る前に、副作用として新しい現状を確立するようです。足りる。 個人的には、問題で提起された理由から、そこでの優先順位は問題があると考えています。 偶然にも、WASIでの取り組みは、以前にCGメンバーがインターフェイスタイプでの私の主張に反対して推進しており、相関関係は必ずしも因果関係を意味するわけではありませんが、最終的にWebAssemblyの一般的な方向性に疑問を投げかけ、この問題に戻りました。

これまでよく見てきたと確信しているWASIの設計原則では、Web上で簡単にポリフィルできるAPIに限定されないことを明示的に述べています。また、WASIは可能な場合はWeb標準で動作する必要があることも明示しています。 。 @ conrad-wattが先に指摘したように、コア言語とエコシステムには違いがあり、ホストが提供しないことを選択できる名前空間です。 エコシステムとしてのWASIにはさまざまな設計目標があり、Web互換性をその目標の1つにすることは、WASIが解決しようとしている問題に対して生産的ではないようです。

今では明らかなように、私たちはコミュニティとして、Webとの優れた互換性を確保するために必要なことを行っていないと同時に、Webとの互換性を壊すための新しい提案や関連技術を容認していることを非常に心配しています。あまりにも多く、またはそうでなければそれに悪影響を及ぼし、直接的または間接的に影響を及ぼします。 これにより、たとえば、Wasm、または少なくともその将来の自己は、一度に1つの重要な部分の下位互換性を損なうため、おそらくW3C勧告ではないのではないかと思いました。これは確かに極端な結論ですが、意見の不一致のレベルがさらに高まるとき、私たちが尋ねなければならない究極の質問だと思います。

コミュニティは、Web標準に取り組んだり、Webに多額の投資をしたりした数人で構成されています。 あなたの懸念を聞いていますが、将来がそれほど悲惨であるかどうかはわかりません。 下位互換性がすでに意味のある方法で損なわれている具体的な例を追加できますか？

そのような背景を踏まえて、私は今日CGに目を向け、将来の不要な摩擦を減らすために、WebAssemblyの全体的な目標に次の追加について話し合うように依頼します。

一般にOpenWebPlatform、特にWeb APIとJavaScriptとの互換性は、WebAssemblyの長期的な成功にとって重要であり、回避できる場合は妥協してはなりません。 この目標に悪影響を及ぼさないためのインセンティブがほとんどない可能性があるため、主にWebを対象としない機能を促進する提案の基準は特に高くなります。

これは私が提唱してきたより高いレベルの側面であり、一言で言えば、私たちがそれに同意し、それを書き留めることができれば、上記の議論の摩擦のほとんどは、少なくとも私にとっては（ほとんど）時代遅れになりますプロセスに私の信仰を取り戻しながら、心配しています。

これが意味すること：

• インターフェイスタイプは問題ありませんが、互換性のためにJS文字列エンコーディングが重要であり、UTF-8を昇格させて穏やかな圧力などを提供したり、意図された傾向で正当化したりすることは問題になる可能性があります
• スレッド、SIMD、i31refなどはすべて問題ありません。これらは無関係であり、機能を追加するだけであるためです。
• GCは問題ありませんが、最終的には相互運用性に適したソリューションを見つけるように動機付けられます。
• WASIは問題ありませんが、断片化ルートをさらに進む前に、現在本質的にlibcであるものの代替案を検討するように動機付けられます。
• WASI-nnは問題ありませんが、たとえばWebCGの機械学習と協力するように動機付けられます。

CGがそのような段落を公式にすることについてコンセンサスを見つけることができない場合、またはそれを大幅に変更する必要がある場合、特にWeb標準であるという観点から、Wasmの将来について非常に心配し、再提案することをお勧めします。 -私たちの目標と私たちが公に伝えていることをより詳細に評価します。 この場合、そのようなコースを合法化するための投票も行いたいと思います。

あなたの考えを教えてください、ありがとう！ :)

プロセスの形で参入障壁を明示的に追加することに戻ることは、実際にはあまりうまく機能しません。厳密なプロセスの観点からこのテキストをどこに含めるかを正確に知っていたとしても、すでに進行中の提案に関する懸念があることを考えると、遡及的に適用されません。 歴史的に、私たちは提案のプロセスを軽量に保ち、前進を促し、CGに任せて意味のある決定を下すことを試みてきました。 プロセスバリアの追加は、CGが誠実に機能していないという前提がある場合にのみこれまでのところ進みます。 これがあなたが示唆していることであるとはまったく言わず、参入障壁は提起された懸念に対処するための特に良い方法ではないというだけです。

@tlively前のコメントで神経質になっているようです。 でも、悪い結果を避けたり、将来の緊張を和らげたりすることが目標である場合、これを十分に考えることは価値があると私は信じているので、しばらくお待ちください。 たとえば、別のより微妙な仮想の極端なシナリオは、「コア提案にも責任を持つアクターが、より広いエコシステムで繁栄するための異なる目標を持つサブグループの結果を与えるために、これらの提案を遅らせるとしたらどうなるでしょうか？それを防ぐことはできませんが、それを思いとどまらせたいですか？」 同様に、私はしばらくの間これについて考えましたが、これはすべて架空のものであり、それがより高い原因になっていることに言及することを強調したいと思います。 私は、OPでの私の提案を、それにつながる私の思考プロセスを理解するのにおそらく関連するかもしれない側面を控えることによって弱めたくありません。 これは別のジレンマかもしれないと私は思います、そして私はできる限り敬意を払うように最善を尽くしています。 たとえば、「これを指摘し、非常に協力的であることに感謝します。お詫びします」という以前の返信を削除しました。 。 私が危機に瀕していると私が信じていることを考えると、これが大丈夫だといいのですが？

@dtigお返事ありがとうございます。 これを読んだことで、WebAssemblyの将来について自信が持てるようになりました。また、これまでの経験は、当初考えていたほどCG全体を代表するものではないという自信もありました。 私が提供できる例は、主にOPでリンクした個々の問題内の議論に基づいており、現在私が認識しているCG活動全体についてはあまり言及していません。 「WASIは可能な限りWeb標準で動作する必要がある」ということも私が強く同意する側面であり、JavaScriptはコンテキストは、そのようなWeb標準であり、WASIでの関連する問題に関するこれまでの私の経験とは一致しません（結果がsyslogのようなインターフェイスであるhttps://github.com/WebAssembly/WASI/issues/402を参照）。 よろしければ、ここで少し考え直さなければなりませんが、この点について議論することに興味があり、WASIの設計原則は交渉不可能であってはならないというより高いレベルの点について議論するでしょう。これまでのところ、WASIはWebAssemblyの傘下にあるため、新しいAPIを作成する自由を与えるだけでなく、コアWebAssemblyに対する潜在的な間接的な影響（認識を高めたい）による責任も意味します。

WASIは良いデザインではないと思います。 まず、Web仮想マシン用に設計されたWebアセンブリ、およびposix互換の一部のAPIの設計は、開発の方向性に沿っていません。 次に、サードパーティのAPIを導入するためのより良い方法は、APIの数を制御し、セキュリティも制御できるように、インターフェイス（2つのドメイン間の相互作用）を定義することです。

もう1つのより微妙な仮想の極端なシナリオは、「コア提案にも責任を持つアクターが、より広いエコシステムで繁栄するためのさまざまな目標を持つサブグループの結果を提供するためにこれらの提案を遅らせるとしたらどうなるでしょうか。それを防ぐことはできませんが、落胆させたいと思います。それ？"

提案に意見の相違があれば、反対派は提案に力を持っているCGに懸念を持ち込むことができると思います。 採用には実装での出荷が必要ですが、すべての実装での出荷は必要ありません（2つが数だと思いますが、しばらくは見ていません）。 実装がある限り、これによって誰かが他の人の希望に反して提案を遅らせることができるかどうかはわかりません。

@penzn残念ながら、プロセスが完璧だったら、私たちはここにいません。 例として、WASIの設計原則に対する私の意見の相違を見ることができます。 WASIは設計によって大きく独立しているため、これらに適切にアプローチする方法がわかりません。WASIは、現代の大多数がそれを良いものと見なしているため、全体像の懸念はWASI自体でのみ提起できますが、懸念を提起するという印象がありました。 WASIでWASIを使用しても、解決につながる可能性はほとんどありません。これは、WASIのほとんどが、当然、WASIを現状のままにしておきたいためです。これは理解できることです。 たとえば、同じグループであり、そこで発生した問題を知っているにもかかわらず、インターフェイスタイプに戻されました。多くの場合、私が指摘するのは「WASIの設計原則と互換性がない」ということです。 そこで私は、より高いレベルの問題を特定しようとしました。私の意見では、WASIは、コアWebAssemblyの目標とほとんど一致しないと同時に、コアWebAssemblyの目標に責任を負わないことが正当化されているということです。 それで、私はプロセスを適応させることを提案します。なぜなら、私はプロセスを使用できないか、そうする権限を感じていないからです。

2021-04-28のCG会議でのCAPIの安全性に関する議論を参照してください。これは、提案内でプレゼンターの懸念が解決されなかった同様の状況でした。 もちろん、WASIの場合の違いは、それが提案ではないということですが、CGは依然として手続き上の権限を持っている必要があります。 C APIの安全性については、CGが反対派を支持した後、提案のチャンピオンが受け入れなければならないという具体的な問題が提起されましたが、最後に投票なしで提示することもできると思います。

申し訳ありませんが、「CAPIの安全性」がより大きな問題に匹敵するかどうかはわかりません。 詳細を教えていただけますか？ たとえば、WASIでプロのWebプレゼンテーションを行うことは、意見の不一致をさらに助長するだけだと思います。 @dtigが言ったように、そうすることは「WASIが解決しようとしている問題に対して生産的ではないようです」。

C APIの安全性に関する議論では、目標とニーズ（安全でない言語のAPIにチェックが必要かどうか）についても高度な意見の不一致があり、CGの議論で解決されました。 これはオープンスタンダードです。提案を行い、議論を開始することが、私たちが実際にそれを変更しなければならない唯一のツールです。

エコシステムの問題に関するいくつかの考え：WebとサーバーAPI間の断片化がリスクであることに同意します。 WASIが追加されたことで、Wasm用に2セットの標準化されたAPIができました。私は個人的に懐疑的であるため、ブラウザーはWASIを採用し、WASIの存在を考えると、その逆もありそうにありません。

WASIがサーバーへのWebAPIの移植に焦点を合わせていれば、Webにとってはもっと良かったでしょう。 しかし、それはWasm全体にとってそれが良かったという意味ではありません。 Node.jsとの比較とそこでのAPI履歴に感謝しますが、それは両方の方向に進むと思います。はい、Node.jsがより多くのWeb APIを使用するのは良かったのですが、Node.jsの大成功は部分的にWebに関係なく必要なAPIを追加します。 おそらく、Wasmがサーバー上で成功するためにはWASIが必要です。Webとサーバーのエコシステムがどれほど異なっているかを考えると、APIの断片化は避けられません。

それが、WASIが始まったときに私が個人的に批判しなかった理由の1つです。 Webの観点からは最適ではありませんが、サーバー上でのWasmの成功には依然として必要である可能性があり、これはWasmの全体的な成功に役立つ可能性があります。 （2番目の理由は、WASIのセキュリティモデルが興味深いものであり、Wasmの繁栄にも役立つ可能性があることです。）

より一般的には、Wasmは、プラグイン、サンドボックスソリューション、ブロックチェーンなど、Webとサーバー以外にもさまざまな方法で拡張されています。 主にある分野で働いている人として、他の分野で働いている人を批判したくありません。 私たちはお互いを遅くするべきではありません。

それに対する唯一の例外は、断片化などの本当に深刻な危険であるべきだと思います。 現在、そのような危険は見られません。 2つの標準APIを使用すると、いくつかの問題が発生し、最適性が低下しますが、サーバー-> Webを既にポリフィルすることができ、最終的にはWeb->サーバーも実行できるようになります。 文字列のような問題の場合、事前インポートはWeb上で最終的に最適な文字列の使用を許可するものと見なします。これによりWasmでのAPIの断片化もより明白になりますが、この場合、ブリッジできない言語の違いのために既存のものです。 全体として、リスクは現実的で厄介ですが、管理可能で避けられないようです。

良い考え、 @ kripken 、これらは代替案の私の理解とほぼ一致しています。

Node.jsの比較に関して、私が特に念頭に置いていたのは、 BufferとUint8Arrayのようなもので、これは依然としてWeb上で多くの（遅い）ポリフィルの原因となっています。 または、他のすべてのポータブルモジュールで回避可能なglobalとwindowのチェックインを行います。 または、起動時間を短縮するために、しばらくの間TextDecoderがグローバルではありません。 または、 crypto.getRandomValuesまだグローバルに利用できません。 または、今日までのESMサポートのすべての落とし穴。 fsなどのサポートはおそらく避けられなかったでしょうが、Node.jsはいくつかの場所でもっとうまくいく可能性があると私は主張します。

WASIでは、WASIファイルシステムが必要になる可能性が非常に高いという点で状況は似ているようですが、エコシステム全体で共通の機能を提供する他のAPI、最初にポータブルベースモジュールを作成するために不可欠なAPIがあります。私たちが現在向かっているところよりもうまくやれると思うところ。 たとえば、何か問題が発生したときにコンソールに書き込み、現在の時刻を取得するモジュールなどを想像してみてください。（完全な）WASIポリフィルによってはやり過ぎのように見えます。 一部のモジュールでは、Web上の（ちょうど）WASIファイルシステムに付随するポリフィルが必要になると思いますが、それは確かに管理しやすいと思います。 私たちはここで私たちがオールオアナッシングの状況にあるとは思いませんが、最終的には「しかし設計原則」に報いる協力の余地はたくさんあると思います。 私の主張は次のとおりです。可能であれば、おそらくそうすべきであり、プロセスを少し適応させる必要がある場合は、同様にすべきです。

事前インポートに関しては、私は個人的に非常に基本的な相互運用のためにこれらに依存することの大ファンではありません。文字列は非常に重要であるため、このレベルでのフラグメント化は私たちが最終的に望んでいるものではないと思います。 たとえば、移植性を必要とするエコシステムは、それが素晴らしいからではなく、まったくの必要性から、最終的にJS文字列を使用するように収束する可能性があると他の場所で述べました。 特に、以前私に同意しなかった人は、私を含めて、そのような結果にあまり満足していなかったと思います。

サーバー側の断片化とブラウザーAPIに準拠することの価値についての名誉ある言及を含む、Denoの最新のブログ投稿からの抜粋です。

ブラウザを超えてWebプログラミングを拡張することは、斬新なアイデアではありません。 実際、「Node.js」プロジェクトでは中程度の成功を収めています。 しかし、10年以上後、サーバーサイドJavaScriptは絶望的に断片化され、悪いインフラストラクチャに深く結びついており、革新するインセンティブなしに委員会によって取り返しのつかないほど支配されていることがわかりました。 ブラウザプラットフォームが急速に進歩するにつれて、サーバー側のJavaScriptは停滞しています。

Denoは、このエコシステムに新しい命を吹き込むための私たちの試みです。 ブラウザAPIに準拠した最新の生産的なプログラミングシステムを提供するため。 Denoはモノリシックシステムではなく、さまざまなニーズに再利用できると私たちが信じている一連のテクノロジーです。 サーバーサイドJavaScriptのすべてのユースケースがファイルシステムにアクセスする必要があるわけではありません。 私たちのインフラストラクチャは、不要なバインディングをコンパイルすることを可能にします。 これにより、ElectronスタイルのGUI、Cloudflareワーカースタイルのサーバーレス関数、データベース用の組み込みスクリプトなど、さまざまなアプリケーション用のカスタムランタイムを作成できます。

もちろん、まったく同じではありませんが、彼らが学んだ教訓から学ぶべきことがまだあるかもしれません。

はい、間違いなく関連記事です。 それからの別の重要な引用：

多くの開発者は、Webファーストの抽象化レイヤーを好むと思います。

Web->サーバーのポリフィリング（前述のとおり）が重要になるもう1つの理由。

補足：WASIと断片化で見られる問題の一部を解決するために、WebAssemblyのSystem Essentialsという名前のビルディングブロックをスケッチしましたが、このようなものが以前に良さそうかどうかについて考えてみたいと思います。何かを提案します（あちらで問題を開いてください）。 誰かが私と同じように価値を見ている（または共同チャンピオン/ガイダンスを提供したい）場合は、私に知らせてください。 そうでない場合は、同等の効果を達成する代替案に興味があります:)

ドキュメントを一目見ただけで、「必須」のリストは完全にシステムの_機能_で構成されています。 それらをデフォルトで提供することは、アンビエント機能の存在を意味し、それによって、Wasmが確立するように注意深く設計されたサンドボックスモデルを弱体化させます。

さらに、そのリストにある機能はどれも、今日Wasmをホストしている環境全体でさえ、普遍的に利用可能であるとは期待できません。 たとえば、ブロックチェーンなどの分散型システムでは、現在の時刻（現地時間は言うまでもなく）、ランダム性、ロギングのいずれも使用できません。

それらをデフォルトで提供することは、アンビエント機能の存在を意味します

おそらく、記憶の存在のように。 それほど違いはないようです。

そしてそれによって、確立するために注意深く設計されたサンドボックスモデルを弱体化させるでしょう。

メモリ、または異なるハードウェア（FP、リラックスSIMD）での非決定論も同様に機能する場合にのみ、私は思います。 私は、Wasmの「注意深い設計」を「弱体化」させるつもりはなかったし、ドキュメントがそうするとは思わない。

そのリストのどの機能も、普遍的に利用可能であると期待することはできません。

Wasmバイナリは、一部のOSの一部のVMを備えた一部のマシンで実行されるため、ここでは同意しません。 特別なユースケースでは使用を制限したい場合でも、これらが世界中で利用可能になることを期待するのは合理的だと思います。

たとえば、ブロックチェーンなどの分散型システムでは、現在の時刻（現地時間は言うまでもなく）、ランダム性、ロギングのいずれも利用できません。

たとえば、ブロックチェーンと言います。 これらは通常、今日の時点で浮動小数点演算を許可せず、同様に時間の取得を許可しないか、ログメッセージを破棄することを決定する場合がありますが、ノードは引き続き一部のOSの一部のVMで実行されます。 また、元帳の正確なユースケースにもよると思いますので、制限が不要なユースケースも多いと思います。 とにかく、Wasmが純粋な意味でこれを解決できるとは思いません。 もう1つの極端な例は、メモリが1ページ未満のIOTデバイスであり、さまざまな影響があります。

一般に、このような本質的なレベルで断片化と戦うことは価値があると思います。結果が私のドキュメントで概説されているものとはまったく異なるものであっても（私はそれを捨てても大丈夫です）、私は明らかにこれを熟考することに興味がありますが、最終的には匹敵する何かを達成します。 建設的でありながら十分な情報に基づいた妥協のように。 そのため、私たちがこれをどのように達成できるかについて、一緒に、また個人的にも考えていただきたいと思います。それは、私のアイデアが、技術的な専門知識で尊敬する人々から価値があると考えられるようになるからです。

とにかく、このディスカッションを私のドキュメントのリポジトリ、Discord、Eメール、またはボイスチャットに移動する方がよい場合があります。 それがあなたの印象でもあるなら、そうしてください（またはそれが最もうまくいくところを私に連絡してください）:)

WebAssembly Core仕様に、OSや時間やロギングの周囲の概念があることなど、実行環境について何も想定させないことには価値があると思います。 Wasmの正式なセマンティクス以外の状態に依存したり、状態を変更したりする場合、Core仕様では、インポートされた関数をキャッチオールエスケープハッチとして作成しますが、もちろん、特定のインポートセットが提供されることは指定されていません。

一般的に、このような本質的なレベルで断片化と戦うことは価値があると思います

これがこのスレッドの不一致の核心だと思います。 個人的には、Core Wasm仕様が統一されたエコシステムを提供しようとすることは目標ではないが、純粋な計算のために可能な限り移植性のある（そしてパフォーマンスの高い）抽象化を提供しようとするべきだと強く感じています。 例えとして、X86もARMも、統合されたエコシステム（または統合されたABI）を提供しようとはしていません。 それはそれらの上にある抽象化のOSレイヤーに任されており、モデルはWebAssemblyにも適していると思います。

そうは言っても、可能な限り生態系の断片化を回避することは明らかに価値がありますが、それはCoreWasmの上のレイヤーで行う必要があると思います。 この生態系統合層の明確な候補はWASIです。 あなたが特定した重要な機能が、Webの内外で最小限の接着剤で動作するように特別に設計されたWASIモジュールによって提供された場合、それは機能しますか？ 時間とランダム性に関する現在のWASI機能はどこで不足していますか？

たぶんそれが必要なのです。標準化された_optional_インポートのセット。 Web、ほとんどのWASIシステム（オプションであり、WASIは制限された組み込み環境で実行される可能性があるため）、および標準のインポートを_オプションで_提供できる場所で利用できます。

Webでは、JSグルーコードがそれらを渡したかのようになりますが、いいえ、システムはそれらを渡し、JS開発者は何もする必要がないか、名前でリストしてどれを選択するかを選択する必要がありました。ご利用いただけます。

Web開発者は、特定のインポートが存在する（またはJS側で選択される）ことを当然のことと見なすことができますが、これはWasm自体にその言語でのインポートを強制するものではありません。

ブロックチェーン環境は、たとえば（オプションの）インポートを提供しない場合があります。

ユーザーは、実行している環境と、使用可能であると文書化されているインポートを知る責任があります。

これは、コンパイラスイッチが異なるAPI呼び出しを出力する必要がないことを意味します。

WASIは、標準のインポートのプロバイダーと、専用のサーバーのみのインポートのプロバイダーの2つになります。

JSを使用せずにWebで標準のインポートを提供する問題は、少し異なる問題だと思います（ただし、 @ dcodeIO 、同意しない場合はお知らせください）。 Web上およびWeb外で使用するための標準のインポートセットが与えられたとしても、現在のJS APIは、モジュールをコンパイルおよびインスタンス化するためにJSを作成する必要があるため、一部のインポートを暗黙的に許可することによるWeb開発者へのわずかなメリットはわずかです。 標準のインポートセットを考えると、ESM統合提案のようなものによって暗黙的に提供されることは理にかなっているかもしれませんが、ここでの問題は、そのような標準のインポートセットがまだないことです。

@dcodeIO

System Essentialsのアイデアは興味深いと思いますが、それらの新しい標準には同意しません。 最適には、WASI（ @tlivelyが言ったように）に入れるか、WebAPIにすることができます。

Web APIについて：新しいDateオブジェクトを必要とするタイムゾーンの取得に関するリンクの公平なポイント。 それはwasmでは面倒です。 ただし、JS Reflect API（具体的にはReflect.construct ）を使用すると可能です。 必要に応じて、JSまたはWasmJSAPI側のいずれかにこのようなAPIを追加できます。 インポートは引き続き宣言する必要がありますが、コードサイズのコストは最小限に抑える必要があります。

WASI APIについては、Web/WASIの格差を埋めるためにさらに多くのことを行う必要があると強く信じています。 より多くのWebフレンドリーなAPIをWASIに追加することは、個人的には理にかなっています-おそらくSystemEssentialsに似ています。 私は先月、別の考えられる方向性を説明し、興味があれば具体的な詳細をスケッチすることを提案しましたが、WASIの人々からの回答はまだありません。 フィードバックは大歓迎です！

私にとって重要な側面は、Webの重要な機能、またはWebのオン/オフの共通機能に必要なグルーコードがあってはならないということです。非常に基本的な機能を必須のポリフィルに依存するエコシステムは、私たちが努力すべきものではないと信じています。ために。 また、WebでもWASIでもポリフィルを必要とせずに、Win-Winで両方の方法で機能するものを見つけられることを願っています（WebからのWeb APIのポリフィルはそれほど問題にならないかもしれませんが、私は両方のために何かをしたい）。

これは、私のやや欠けている「System Essentials」命令のアイデアが由来しているところです。これは、インポート名前空間の追加は、以前に提起された理由でブラウザではおそらく発生しないという私の観察に基づいているため、おそらく命令が実際に発生する可能性があるというのが私の直感でした。反対する良い議論がありますが、問題は少なくなります。 コアWasmを「コア」に保つことについてのあなたの意見に同意します。そして、Web+WASIの両方で機能するコアWasmの上にもっと良いことができることを願っています。

そのため、私は自分の特定のアイデアに特に執着しているわけではなく、[x]のボックスにチェックマークを付けると、グルーコードが削除されます。 、またはESM統合を介して間接的に、Webからその一部をサポートすることで、最終的に[x]断片化を減らすことができます（共通の機能のみを使用する場合、同じモジュールがWebの内外で実行され、ポリフィルなしで実行されます。ファイルシステムとDOMで線を引きます。 、どちらかと言えば環境固有です）。 それは理にかなっていますか？ :)

別の考え：おそらく、私たちの会話は、サブ言語のアイデアを知らせるのに役立つかもしれません-「web + wasi」の「プロファイル」などと言ってみませんか？ 次に、サブ言語APIサーフェス間の共通部分を標準化することに要約できます。

また、この問題は1か月近く公開されており、残念ながらIT / WASIの人々が状況を改善するために声をかけることはほとんどないため、私は紛争分析を試してみることにしました。

以下は非常に主観的なものであり、実際には、Wasmランドスケープの私の新たなメンタルモデルを表しているにすぎないことを強調したいと思います。 それは、誰かが悪いことをしていることを意味するものではなく、焦点がさまざまであるということだけを意味します。これは当然のことです。 不当な扱いを受けたと感じた場合はお知らせください。これは私の意図ではありません。訂正または削除します。

私の目標は、Wasmをより豊かにすること、つまり、より多くの機能とユースケースを含めること、つまり、それぞれ純粋に保つこと、つまり最小限のISAの要点を強調することに関して、Wasmプレーヤー間の整合性、またはその欠如を特定することでした。コインの特定の側面に焦点を当てます。ここでは、主にWebプラットフォーム上でそれぞれエッジ上またはブロックチェーン内でWasmを実行することに関心があり、多くの場合、要件が大きく異なります。

• ブラウザ：本質的にかなり豊富なWebプラットフォームを提供します。 いわば「新しいデスクトップOS」。
• サーバー：「自分のものを持参する」のように、本質的に比較的必要最低限​​のものです。 中性。
• 調査：他の俳優に執着しない限り、Wasmをすべての人にとって良いものにしたいと考えています。
• Google：Webへの移植と高速化に重点を置いています。 他の人のニーズを害しない限り、他の人のニーズを考慮しても大丈夫ですか？
• Dfinity：ブロックチェーンのオールイン。 どうやらいくつかの豊かな機能が必要です。 しかし、ベアボーンが多ければ多いほど良いのでしょうか？
• 高速：エッジ重視。 リーン/最小限のVMは、製品にとって重要です。 IT / WASIに効果的に責任がありますか？
• Apple：Webで機能するものでOK。 必ずしもAppStoreとの競争に熱心ではありませんか？
• AssemblyScript：実際の実用性を求めています。 Webの傾向がありますが、Edge / BCの利害関係者のためにややあいまいですか？
• Intel?:これまでのところ多くの兆候はありません。 効率的なコンピューティングに主に興味がありますか？
• Redhat?:これまでのところ多くの兆候はありません。 主にインフラストラクチャに関心がありますか？
• Microsoft?:これまでのところ多くの兆候はありません。 .NET on the Webそして最終的にはどこでも？
• Mozilla ?:存在しませんか？

これは多くのレベルで間違っている可能性がありますが、私のメンタルモデルを比較的よく示していることがわかりました。 また、「WebAssemblyのWeb」が私の期待から機能すると考える線を引きましたが、これも議論の余地があります。 どちらかといえば、私がどこから来たのか、なぜWasm-landで何かがおかしいという印象を受けたのかを理解するのに役立つと同時に、この問題の私の凝縮された見方に興味を持っている人々のために状況に光を当てることを願っていますしかし、起こったすべての詳細を認識していない可能性があります。 取ってください、しかし塩の粒で:)

2ペニー...この会話がこれまでに起こらなければならなかったことに私は本当に驚いています。 WebAssemblyにとって、アーリーアダプターが思いついたユースケースでスコープを定義できるようにすることは常に悪い考えでした。

Webは、特にWebAssemblyのレベルで、開発者が実行できることを制限する必要があるため、他のプラットフォームにはない方法でWebAssemblyを必要とします。

WebAssemblyが暗号マイナーが嫌う方向に進んだ場合、WebAssemblyはそれをフォークすることができます。 これは、Web標準を設計するときに気にする必要のあることではありません。 他のすべての人は、基盤となるプラットフォームを完全に制御できます。 Webには、与えられたプラットフォームしかありません。それが標準になると、私たちは永遠にそれに固執します。

WASIは、独自の機能を実行するために分岐する必要があります。また、Webには、ブラウザー専用に完全に最適化された独自のVMが必要です。

WebAssemblyにとって、アーリーアダプターが思いついたユースケースでスコープを定義できるようにすることは常に悪い考えでした。

実際、その範囲はCGによって定義されており、あなたを含む誰でも参加できます。 そこでは、人々は方向性に投票します。方向性に積極的に取り組むことに時間を費やしたい場合は、方向性に影響を与える可能性があり、よく考えられた技術的な議論を提示します。

必要に応じて、誰でもすでにWasmをフォークできますが、共有エコシステムには多くの利点があるため、最も関心のある関係者はそれを求めています。

誰もがCGに参加できるということは、Web以外の関心を持つ人々の参加を阻止できないことを意味します。

私はこの会話がこれまでに起こらなければならなかったことに本当に驚いています。 WebAssemblyにとって、アーリーアダプターが思いついたユースケースでスコープを定義できるようにすることは常に悪い考えでした。
..。
WASIは、独自のことを行うために分岐する必要があります

WASIは独自のことをしています。 インポート名前空間です。 WebAssembly言語機能と同じレベルで標準化されていません。 Web以外の機能を範囲外と宣言し、コミュニティグループの名目上の傘下でWASI仕様を実行することを許可しないという提案はありますか？ 断片化を防ぐという点で、それは何を達成するでしょうか？

WASIの特定の部分を微調整してよりきちんとシム可能にすることができるかどうかを調査することにはメリットがあります（Web-> WASI、または@kripkenがここに配置されているWASI- > Webの両方）が、最悪の場合でも、最終的にはWASIが非Webランタイムのサードパーティプロジェクトとして完成したかのように、WebにインポートできないAPI。

繰り返しになりますが、 @ dcodeIOにリンクされている問題を読んでみると、WebがWebAssemblyにとって重要ではないと考える人は誰もいません。 私が見ているのは、文字列エンコーディングのようなかなり特定の相互運用の摩擦を解決するための機能/ロードマップについて（時には無礼に）意見が分かれている人々だけです。 私は、これらの技術的な不一致をWebとWeb以外の権力闘争の証拠として特徴付けることは誤りであり、そうすることで前向きな結果が得られないと強く信じています。

私はそれを権力闘争とは見ていません。スコープが広すぎて事実上オープンエンドであるという問題と同じくらいです。 World Wide Webは、独自の仕様と標準を備えた独自のVMを独自の条件で使用し、独自の命名法を使用するのに十分重要です。 すべてを一般的で抽象的なものにしようとする試みは、Web開発者にとってなじみがなく、しばしば異質な仕様、ドキュメント、および会話につながりました。

明確にするために、WASIが公式プロジェクトであるという問題は純粋に象徴的です。 技術的な違いはありませんが、そのステータスから、WebがWebAssemblyを使用していることは明らかですが、Webによって作成されたテクノロジーではありません。

私はそれを権力闘争とは見ていません...

@ 7ombie申し訳ありませんが、私の最後の段落は、主に上記の「競合」の図についてコメントすることを目的としていました。

すべてを一般的で抽象的なものにしようとする試みは、Web開発者にとってなじみがなく、しばしば異質な仕様、ドキュメント、および会話につながりました。

私は、インターフェースタイプに関する技術的な期待のいくつかが特に非常に難解になっていることに同意します。 CGには確かに、「ファーストクラスの文字列タイプではなくインターフェイスタイプ」などの会話の余地があります。プロセスを機能させ続けるために、 @dcodeIOのようなWeb中心の開発者が意見や懸念を共有することに依存しています。 これについての最後の会話が終わった方法に私はがっかりしました、そして私たちは将来もっと良くできることを願っています。

了解しました、@conrad-watt。 私はその会話を見たことがありませんが、私としては、WebVsを試してみたいとは思っていません。 Web以外の考え方、またはそのようなもの。 私は、一般的に非常に満足し、興奮し、感謝しているテクノロジーと個人的な不満を共有しているだけです。

私の以前のコメントはかなり批判的で露骨でしたが、私はただカジュアルでした。 私は動揺していませんよ。

@ conrad-wattetal。 インターフェイスタイプの技術的な説明は、近い将来、より難解になる前に、より難解になる可能性があります。 説明として、これの多くは、再利用性と厳密さを組み合わせたいという願望によって推進されています。

合理的に可能な限り（WASIなどと）協力することにも価値があることを強調したいので、交差点をカバーする方法で生態系間の移植性につながる解決策を調査す​​ることを提案しました。 'dは現在線を引いています（DOM、ファイルシステム）。 私が提案していることは難しいかもしれないし、同等の何かを達成するためのより良い方法があるかもしれないことを私は知っています（私に知らせてください！:)）。 それだけです（OPで自分自身を引用するために）

私たちはコミュニティとして、Webとの優れた互換性を確保するために必要なことを行っていないと同時に、Webとの互換性を壊しすぎたり、影響を及ぼしたりする新しい提案や関連技術を容認しているのではないかと非常に心配しています。否定的に、直接的に、または間接的に。

それを明確にすることによって、私たちの目標を何らかの形で再評価することを提案するように私を導きました

一般にOpenWebPlatform、特にWeb APIとJavaScriptとの互換性は、WebAssemblyの長期的な成功にとって重要であり、回避できる場合は妥協してはなりません。 この目標に悪影響を及ぼさないためのインセンティブがほとんどない可能性があるため、主にWebを対象としない機能を促進する提案の基準は特に高くなります。

提起された多くの点に同意するので、私はOPにいたときほど、これを提案の要件にすることに執着していません（これはそうなるかもしれないと示唆されました）が、それでも私たちを効果的にシフトする集中的な努力に感謝しますその方向に。

@dcodeIO 、あなたの対立分析で考えられる議論の項目は何ですか、あなたがリストしたすべての会社は彼らの計画を明らかにして比較する必要がありますか？ あなたはそれが可能だと思いますか、そしてそれは何を達成するつもりですか？

チャート内のどの企業についても実際にコメントすることはできませんが、他の企業が同意しない限り、単一のエンティティが自分たちの基準を変更することはできないため、このように比較することは誤解を招くと思います。 また、チャートの軸は主観的で紛らわしいと思います。 たとえば、Web上のwasmでコンピューティング（レンダリングやNNなど）を実行すると、コンピューティングが「クラウド」から下に移動するため、「エッジ」である必要がありますが、それは重要な部分であるため、「ウェブ」でもある必要があります。インタラクティブWebの現在（クライアントマシン上で実行されるため、「サーバー」ではありません）。 定義の純粋さと豊かさは相対的な用語であるため、もう1つの側面はさらに主観的なIMOです。 例-Goの呼び出し規約によって動機付けられた制御フローの制限については、非常に長い間議論されています。 誰に尋ねるかによって、これらの制限は有用な機能または不要な機能と見なされ、その人が「リッチvsピュア」軸のどこに議論を置くかに影響すると思います。

直接質問するために、WebAssemblyの長期的な方向性は、それを採用する人によって定義されますか？ たとえば、Web開発者による長期的な採用は少ないものの、Webとは関係のない目的でWebAssemblyを使用するために数十億ドルを投資している大規模な産業プレーヤーがいた場合、最終的には彼らのニーズが優先されるでしょうか。

直接質問するために、WebAssemblyの長期的な方向性は、それを採用する人によって定義されますか？ たとえば、Web開発者による長期的な採用は少ないものの、Webとは関係のない目的でWebAssemblyを使用するために数十億ドルを投資している大規模な産業プレーヤーがいた場合、最終的には彼らのニーズが優先されるでしょうか。

私たちはコミュニティ/コンセンサス主導の標準です。 基本的に、これらの仮想的な状況は、いかなる種類の正式な手順によっても防御することができないため、これらの仮想的な状況を検討することにはあまり意味がありません。 コミュニティ/合意形成の実存的不安へようこそ。

はい、Wasmを気にかけているのが筋金入りのエッジコンピューティングエンジニアだけだったとしたら、言語はその方向に導かれる可能性があります。 このシナリオでは、Web互換機能のみをCGで標準化できるという原則をなんとかして石に刻み込んだとしても、これはフォークになるか、言語に取り組んでいる人がいないことになります。

明確にするために、私はこれが私たちの状況であるとは絶対に信じていません。Webの利益がCGメンバーによって適切に表されていることを信頼するか、自分自身に関与する必要があります。

ほら、これは私にはわからないことです。 目標は明らかに、W3Cの傘下で、非常に明確な原則と価値観、および同様の課題の長い歴史からの多くの経験を持つWeb標準を作成することです。 Webをリードし、フォークを持っているすべての人がWebの人々が思いついたものと一致しているとしたら、それが彼らの望むものであるとすれば、それがさらに悪化することはわかりません。 そうです、私は最初にWeb用にWebAssemblyを作成し、次に他のすべて用にWebAssemblyを作成することを提案しています。これまでの私の経験が何か価値がある場合、その逆は耐え難い状況です。 それが何を必要とするとしても、それが問題の根本的な原因であると私は考え、それについて話し合う必要があります。

上で述べたように、WebがWebAssemblyの優先事項であることに同意しますが、他のCGメンバーとの技術的な不一致は、主にWebと非Webの派閥の分裂によるものではないと思います。 。 純粋にWebに焦点を当てている人々でさえ、あなたの提案のいくつかに代わるものを追求したいと思う理由があります。これを、あなたに反対する人々がWebを気にしないという証拠として解釈すべきではありません。

WASIはW3C仕様になることはなく、W3CWebAssembly仕様の作成に干渉することもありません。 WASIは「非Web」であるため、CGの下で開発されるべきではないと宣言しても、関係者がWebに注意を向けることはありません。 それは、コミュニケーションとコラボレーションの貴重なラインを閉鎖するだけであり、それにより、（たとえば）いくつかの架空のWeb対応APIとの重複を見つけることができるかもしれません。

公正な点ですが、私はあなたの立場を私が経験したすべてのものと調和させることができないので、そこでは根本的に同意しません。 問題が存在し、それについて私たちにできることは何もないと絶えず私に言うのではなく、対処しなければならないという非常に明確な兆候がすでにあると思います。 私には、これはばかげているように思えます。かつてはWeb標準の中で最も輝かしいスターであり、かつてのWebAssemblyに対応していないことを、人々がWebAssemblyに対して行っていることを恥じるべきであるという点までです。

問題が存在し、それについて私たちにできることは何もないと絶えず私に言うのではなく、対処しなければならないという非常に明確な兆候がすでにあると思います。

何もできないと判断するのではなく、問題を把握できていないと思います。 WASIまたはインターフェイスタイプを改善することに明らかな関心がありますが、それらが根本的に壊れているか間違っているというコンセンサスがあるようには見えません。

問題のロックを解除していただきありがとうございます:)ここでのメルトダウンについてお詫び申し上げます。これは問題があり、自分自身にはるかに良いことを期待しています。 この（私が思うに）重要な問題について話し合うことを含めて、グループと関わり続けたいと思います。そして、建設的な方法でこれを行うことができることを示したいと思います。

最初に、文字列エンコーディングに関する懸念についてのプレゼンテーションを提案しました。これは、インターフェイスタイプの次のステップ、およびコンポーネントモデルに向けた最近の開発にそれぞれ関連すると思います。 そしてその過程で、最終的には、6月22日のCGビデオ会議で話し合いの時間を予定して、事前に録音されたプレゼンテーションの新しい形式を試すことにしました。 録音はこのコメントのすぐ上にリンクされている付随する問題で見つけることができます、そしてそれがより凝縮された、建設的な方法で必要な背景を提供するのに役立つことを願っています。

気楽な提案をすることができれば：誰かがWebブラウザのソースコードの非WASM部分をBinaryenまたはRustで再コンパイルし、デスクトップ上のWASIをターゲットにする場合、ブラウザのほとんどは大きなポリフィル、それともそれ自体が議論を内側に向け、壊滅的な崩壊を引き起こし、地球をブラックホールに変えるのでしょうか？

重大な注意点として、IIRCのウェブは、CERNにあるティムバーナーズリー卿の電話帳のハイパーリンクされたドキュメントとして始まりました。 Web自体は、複雑さやメモリ消費などの期待をすべて上回っています。 Webブラウザーは、ドキュメントビューアーからパブリッシングメディア全体へと進化しました。 それがフィーチャークリープです。

プログラミング環境としてのWASIは、パブリッシングと双方向性が融合するコンピューターサイエンスの分野として、Webテクノロジーをそのルーツに戻す可能性を秘めています。 Webテクノロジーになるためにチャットルームをブラウザで実行する必要があるのはいつからですか？ 元のチャットプロトコルであるIRCは、とにかくWebブラウザよりも長い間使用されてきました。 同様に、SMTPはWWWよりも前のものであり、FTPも同様です。 インターネットは単なるウェブよりも大きく、それが本来あるべき姿です。