Design: هل يجب أن يعتبر WebAssembly التوافق مع النظام الأساسي للويب المفتوح أمرًا بالغ الأهمية؟

أتفق بشكل عام مع البيان كما هو مكتوب ، لكنني لا أعتقد أن أي نوع من الالتزام الرسمي به كان سيتجنب العديد من الخلافات التي ربطتها بها. على وجه الخصوص ، تتم صياغة بيانك في المقام الأول باعتباره عائقًا إضافيًا لاعتماد المقترحات ، ولكن في العديد من القضايا المرتبطة تدافع عن إضافات إلى اللغة الأساسية.

قد تكون تجربة فكرية مفيدة للنظر في الموقف الافتراضي المتطرف "إذا كانت إحدى الميزات تساعد في التوافق مع الويب ، فيجب أن نضيفها إلى Wasm" ، وهو ما لن أتفق معه لأنه سينتهي به الأمر إلى تضخم اللغة بمجموعة من خطافات خاصة بـ JS. أنا لا أقصد ضمنيًا أنك تدافع عن مثل هذا الموقف ، لكنني أعتقد أن بيانك كما هو مكتوب في OP لا يعكس الخلافات المفاهيمية التي يبدو أنها تظهر في القضايا التي ربطتها.

هناك أيضًا تمييز بين "WebAssembly" اللغة الأساسية (والتي أشعر أنه يجب أن تظل متوافقة تمامًا مع "Open Web Platform") والنظام البيئي للأدوات وواجهات المضيف واستيراد مساحات الأسماء التي قد يختار المرء توحيدها / هندستها حولها . من غير المهم أن تظل WASI "صديقة للويب" ، لأنها مساحة اسم استيراد يمكن للمضيفين ببساطة اختيار عدم تقديمها. في أسوأ الأحوال ، قد يتسبب ذلك في مضاعفة الجهود / تقسيم سلسلة الأدوات إذا قام شخص ما لاحقًا بتوحيد واجهة برمجة تطبيقات أكثر ملاءمة للويب.

نعم ، بعض هذه القضايا على الجانب الأقدم قليلاً ، وأنا بالتأكيد سأتناولها بشكل مختلف اليوم (أكثر من ذلك إذا كان مثل هذا الالتزام موجودًا في ذلك الوقت). سأفكر قليلاً في هذا الموضوع ونقاطك الأخرى :)

لقد فوجئت قليلاً بالانطباع بأنني أدافع عن إضافات إلى اللغة الأساسية في العديد من القضايا ، لذلك ربما يكون من الجيد إعطاء بعض السياق. من حين لآخر ، عملت بالفعل على إيجاد بديل للجيب الخلفي (على ما أعتقد) حيث بدا مفيدًا في سياق المناقشة ، والذي يمكن اعتباره داعيًا لإضافات أعتقد ، وعلى الأخص سلاسل عالمية حيث حاولت المساعدة في حل الجمود الملحوظ بين Interface الأنواع و GC اللذان كانا يشيران إلى بعضهما البعض ليكونا مسؤولين عن اهتماماتي. بعد فوات الأوان ، يؤسفني طرح هذا مرة أخرى في قضية تكنولوجيا المعلومات ، حيث يبدو أن GC هو المكان الأنسب. ربما لا يزال قد انفجر هناك ، إذن ، لست متأكدًا. في نهاية المطاف ، لم أقترح هذه الأشياء مطلقًا ، نظرًا للتوترات القائمة أيضًا ، لكنني أوجدتها في الغالب بدافع الرغبة في شرح ما أعنيه بشكل ملموس. في الإدراك المتأخر ، إنها معضلة أجد نفسي فيها إلى حد ما ، حيث يبدو أن اقتراح أي شيء محكوم عليه بالفشل على أي حال بسبب التوتر ، كما أن العمل على حججي بمزيد من التفصيل هو كذلك ، لذلك إذا كان بإمكاننا جعل حياة الجميع أسهل قليلاً من خلال جعل أهداف WebAssembly أكثر وضوحًا ، والعمل على حل الخلاف العام ، سأقدر ذلك كثيرًا.

الموقف المتطرف الافتراضي مثير للاهتمام تمامًا ، حيث أود أن أزعم أيضًا أن هناك ميزات JS قديمة قد لا يتعين على Wasm أن تقلق بشأنها بشكل استباقي ، أو ربما لا تقلق على الإطلاق ، ولكن بعد ذلك لا يزال هناك خط يتم رسمه في مكان ما. يخبرني حدسي أن ميزة واحدة أكثر من اللازم أفضل من ميزة قليلة جدًا ، على سبيل المثال ، لأن التوافق مهم جدًا. مع الالتزام في مكانه ، ربما يكون من المرجح على الأقل أنه يمكن مناقشة سمة تهم أقلية بأقل احتكاك ، ولديها فرصة أفضل للنجاح لتحقيق الهدف الأعلى؟

التمييز بين اللغة الأساسية والنظام البيئي الأوسع مثير للاهتمام بالمثل. أود أن أزعم أنه إذا استطعنا ، يجب أن نحاول تجنب السير في مسار مشاكل النظام البيئي المستقبلية وعدم التوافق ، ويجب أن نتحدث أكثر عن تجنب التجزئة بين Wasm على الويب و Wasm off الويب على سبيل المثال ، والذي يبدو أنه الموضوع إلى حد كبير غير موجود حتى اليوم. على سبيل المثال ، في النظام البيئي Node.js ، اتضح أن جميع واجهات برمجة التطبيقات المخصصة التي تم اختراعها لغير الويب كانت رائعة في البداية ، ولكنها أيضًا تمثل عبئًا اليوم ، نظرًا لأن التمسك بواجهات برمجة تطبيقات الويب (إعادة استخدام) أفضل بشكل عام على polyfill الإلزامي. لقد أدركت Deno ، وهي المحاولة الثانية في Node.js ، ذلك ، لكن النظام البيئي الأوسع عالق الآن معه لفترة طويلة.

لا أعرف كم سيكون من المفيد تجنب تكرار الجهود. من المفيد أن يكون خيارًا ، طالما أنه لا يؤدي إلى مسار تجزئة كان من الممكن تجنبه لولا ذلك؟ على سبيل المثال ، يعد WASI شبه قياسي تحت مظلة WebAssembly بالفعل الذي يتسلل الآن إلى Wasm على الويب ، وكلما زاد نضجه ، أصبح من الصعب إصلاح مشكلات النظام البيئي التي نكتشفها في هذه العملية ، لذلك توجد آلية لمنع مثل هذا النتيجة قبل فوات الأوان تبدو مفيدة.

لا يمكن أن يكون لدينا أشياء مطلقة في أهداف التصميم الخاصة بنا أن Wasm يجب أن يكون الأمثل لنظام بيئي معين أو حالة استخدام ، لأن Wasm يخدم بشكل أساسي العديد من الأنظمة البيئية ، وحالات الاستخدام واللغات ، والتي تتطلب دائمًا مستوى معينًا من التسوية.

إلى جانب الويب وغير الويب ، ركز تصميم Wasm حتى الآن بشكل كبير على جلب مجموعة أوسع من اللغات إلى الويب ، والتي غالبًا ما تكون لغات مختلفة تمامًا عن قصد JS ، لأنها تكمل قدرات JS الحالية أكثر ، وبالتالي فإن الجمع بين JS + Wasm هو الأقوى. كما أنه يسمح بإحضار أكبر قدر من البرامج الحالية إلى الويب ، ويسمح للويب بالوصول إلى مستويات جديدة من الأداء. إذا تم تصميم Wasm بدلاً من ذلك لتفضيل اللغات المشابهة جدًا لـ JS ، فسيكون ذلك بلا فائدة.

هذا أمر جيد ، ولكن من الطبيعي أن تكون هذه اللغات مختلفة عندما يتعلق الأمر بتفاصيل التنفيذ لأشياء مثل إدارة الذاكرة ، والسلاسل ، وما إلى ذلك ، ويجب أخذ احتياجاتهم في الاعتبار ، خاصة وأن الهدف الكامل من استخدام هذه اللغات هو تسمح لهم بأن يكونوا فعالين في هذا السياق الجديد. عندما يتعلق الأمر بالتداخل عند الحد ، لا يلزم فقط النظر في التداخل مع JS ، ولكن أيضًا التفاعل بين لغات Wasm المتعددة ، وفي المستقبل ، التداخل بين هذه اللغات والرمز الأصلي للمتصفحات ومضيفات Wasm الأخرى ، والتي سوف غالبًا ما تكون نفس اللغات أو لغات متشابهة. تحاول المقترحات مثل أنواع الواجهة تحقيق التوازن بين جميع هذه المتطلبات ، وليس واحدًا منها فقط.

أعتقد أن هناك سوء فهم آخر في اللعب قد يكون من الجيد التحدث عنه. لقد كنت بالفعل أدعو إلى النظر في احتياجات مشروعي ، في البداية بشكل أكبر كما كنت آمل أن يكون منظوره الفريد نوعًا ما (أعتقد أن بعض مشكلات AssemblyScript اليوم هي كناري لمشاكل WebAssembly في الغد) سيكون ذا قيمة لـ CG ، ولكن مؤخرًا وخاصة اليوم أنا لا أدافع عن لغة معينة ولكن من أجل الهدف الأسمى المتمثل في التوافق على الويب ، بينما آمل أن أحسن استغلال الفرصة لحل الخلاف بين المجموعة. مثلك تمامًا ، أعتقد بشدة أن Wasm لا ينبغي أن يفضل لغة معينة ، وأخشى أننا نفقد مسار الجوانب الأكثر أهمية مثل التوافق بين معايير الويب على الجدال مع أو ضد لغات معينة ، مما يؤدي إلى مناقشات من المرجح جدًا أن تصبح أكثر سخونة من أن تكون بناءة ، مما يؤدي بدوره إلى تعطيل تطور WebAssembly. لإعطاء مثال ، فإنني أتخذ إهانة طفيفة من طريقة صياغتك لتعليقك ، حيث أشعر أنه يتضمن بعض الأشياء التي قد تكون مدرجة في جدول أعمالي ولكنها ليست كذلك ، بينما أتفق في الواقع مع نقاط المستوى الأعلى الخاصة بك بعدم تفضيل لغة معينة ، تكمل قدرات JS الحالية ، وتوازن بين جميع المتطلبات ، وتقدم التنازلات عند الضرورة ، وتعمل على الوصول إلى مستويات جديدة من الأداء ، طالما أنها لا تؤدي إلى معيار ويب لم يعد معيارًا للويب بعد الآن ، والذي سيكون سيء الحظ جدا.

أولاً ، أود أن أقول إنني أرى تجربتك مع وجود خصوم في CG كعلامة على فشل العملية. ليس من غير المعقول أن نعمل بدون خصومة ، حتى عندما نختلف بشدة مع بعضنا البعض على التفاصيل الفنية أو الأولويات.

ثانيًا ، أوافق على أن قابلية التشغيل البيني مع JS مهمة لنجاح Core WebAssembly. يتضمن ذلك مقترحات مثل GC و EH ، والتي لم توضح بشكل كامل واجهات برمجة تطبيقات JS حتى الآن ، ولكنها ستتم توحيدها قبل أن يتم توحيدها. هناك أيضًا المجموعة الفرعية للمكدس ، والتي تعتبر JS interop أول مسألة عمل لها. أود أيضًا أن أدرج في هذا البيان مقترحات أخرى مثل تكنولوجيا المعلومات التي يتم وضعها في طبقات ، ربما عبر مواصفات منفصلة ، فوق Core WebAssembly ، ولكن لا يزال من المفترض أن يتم دمجها في منصة الويب.

أعتقد أن حساب التفاضل والتكامل مختلف بالنسبة للمستهلكين من غير مستخدمي الويب لمواصفات Core WebAssembly بشكل عام ، و WASI بشكل خاص. لا أعتقد أن CG يجب (أو يمكنه) محاولة فرض أي سيطرة على كيفية استخدام Core WebAssembly أو تضمينه خارج النظام الأساسي للويب ، وبما أن المجموعة الفرعية WASI لا تقترح حاليًا أي تغييرات على النظام الأساسي للويب ، فأنا لا أعتقد أنه من المنطقي تثبيته بالتزامات توافق الويب. ضع في اعتبارك أن المجموعة الفرعية WASI يمكنها دائمًا القيام بنفس العمل مع نفس الأهداف في بعض مؤسسات المعايير الأخرى ، لكننا جميعًا أفضل حالًا من حيث التعاون والتلاقح بين الأفكار والنفقات التنظيمية (ناهيك عن التوافق! ) لأنها مجموعة فرعية من CG.

عند الحديث عن التفاضل والتكامل ، قد يكون السيناريو المتطرف الافتراضي "ماذا لو تصرفت مجموعة فرعية بقصد خبيث للتأثير على WebAssembly الأساسي / العمل حول أهدافها الأعلى" مثيرًا للاهتمام هنا أيضًا ، والذي أعتقد أن الكثيرين سيتفقون معي ليس هو الحال عندما المجموعة الفرعية هي WASI ، لكني ما زلت أرغب في زيادة الوعي ، نظرًا لأن تضمين أو استبعاد ميزات أنواع الواجهة على سبيل المثال ، وهو اقتراح أساسي مدفوع بفعالية من نفس المجموعة ، يمكن بسهولة تحديد أولويات احتياجات WASI ، -ويب مجموعة فرعية ذات لغة معينة ، فوق احتياجات الآخرين. من وجهة نظري اعتبارًا من OP ، ربما تكون قد شاهدت هذا الأخير بالفعل ، لذلك أجادل أن مجرد الحذر من المخاطر واتخاذ الاحتياطات ليس بالضرورة أمرًا سيئًا ، خاصةً عندما تتماشى جهود المجموعة الفرعية مع مصالح الأغلبية ، قد يكون من الصعب إدراك الآثار الجانبية قبل حدوث الضرر الذي لحق بـ WebAssembly الأساسي أو النظام البيئي الأوسع أو حتى معيار الويب الأسوأ. أو بعبارة أخرى: أعتقد أن كونك مجموعة فرعية تحت مظلة WebAssembly يجب أن يعني المسؤولية عن WebAssembly الأساسي وأهدافه الأعلى.

أعتقد أنه سيكون من الجيد أن نكون أكثر تحفظًا قليلاً بشأن عزو الحقد إلى مجموعات مختلفة ، حتى من الناحية الافتراضية ؛)

الكثير من هذه القضايا الخلافية ، لا سيما في مقترح تكنولوجيا المعلومات ، والذي لا يتابعه الكثير من الناس عن كثب ، يشتمل فقط على عدد قليل من الأشخاص ويشاهدهم. بالنسبة لقضايا التصميم عالية الوضوح ، من الصعب التوصل إلى قرار بأن غالبية CG ستكون ضده لأن مجموعة فرعية تمثيلية إلى حد ما من CG تشارك في عملية التصميم ، أو على الأقل تتبعها دون اعتراض. بالنسبة للقضايا المتخصصة ، على الرغم من ذلك ، من الممكن التوصل إلى قرار من بين عدد قليل من الأشخاص بأن مجموعة الحوكمة الكاملة لن تكون مريحة معهم. في هذه الحالات ، قد يكون من المفيد إثارة القضية المحددة في اجتماع CG لأخذ نبض CG الكامل في الاتجاه المقترح.

أحد الأمثلة الحديثة على ذلك كان عندما أثار lukewagner مسألة عدم السماح بالواردات المكررة. كما جربت ، لم يكن CG مرتاحًا تمامًا للاتجاه الذي توصل إليه الأشخاص الذين ربطوا الوحدة النمطية ، ونتيجة لذلك كانت هناك مشاركة أوسع في تلك المناقشة وتحول الإجماع في اتجاه مختلف.

في النهاية ، لن يتم تقديم المقترحات التي لن يكون CG مرتاحًا لها من قبل CG. بالطبع ، تم طرح القضايا السابقة ومناقشتها ، كان ذلك أفضل. آمل أن يشعر الجميع بالقدرة على إثارة القضايا في اجتماعات حوكمة الشركات عند تحديدها.

بذكر هذا أولاً وقبل كل شيء - أعتقد أن قابلية التشغيل البيني مع النظام الأساسي للويب أمر بالغ الأهمية لاعتماد WebAssembly ، وأنا أوافق بشكل عام على نقاطك حول التوافق. ومع ذلك ، لست متأكدًا من أن إضافة حواجز الدخول إلى المقترحات ستؤدي إلى نتيجة إيجابية. يتكون WebAssembly CG من الأشخاص في المجتمع ، ويمكن أن يكون لديهم جميعًا أهدافًا مختلفة مع المساهمة في تطوير المعيار بشكل إيجابي. قد يؤدي وجود أهداف مختلفة أحيانًا إلى احتكاك ، وآمل أن يكون هذا مكانًا يمكننا فيه الاختلاف باحترام عند العمل نحو أهداف مختلفة.

لقد اقترح علي أن أتناول الاهتمامات التالية فيما يتعلق بالاتجاه العام لـ WebAssembly قبل منتدى على مستوى CG أكثر ، وهي نصيحة أتبعها الآن على أمل أن نتمكن كمجتمع من حلها نهائيًا.

كما قد يعرف البعض ، فإن وجهة نظري حول أهداف WebAssembly كانت تتعارض مع أفكار مجموعة معينة مسؤولة عن مقترحات مختلفة لفترة طويلة ، مما يؤدي غالبًا إلى مناقشات ساخنة إلى حد ما. لذلك أعتقد أن هناك فرصة هنا لتحديد جذور الخلاف والعمل على حله ، حتى نتمكن في النهاية من التوافق مع الأهداف المشتركة مرة أخرى. لا يمكنني التحدث إلا من وجهة نظري ، وهي وجهة نظر أكثر شيوعًا بين الأشخاص المهتمين بتشغيل WebAssembly على الويب و _ أيضًا_ خارج الويب ، وهو ما أعمل عليه من قبيل الصدفة بالضبط ، وأنا مهتم جدًا بأفكار الآخرين.

من وجهة نظري ، ينبع الخلاف من التوقع الناجم عن مبدئيًا ولا يزال يتم الإعلان عن WebAssembly باعتباره جزءًا من Open Web Platform (سأختصر كلمة "الويب" أدناه). على سبيل المثال ، تم التعبير عدة مرات عن أن Wasm لا يُقصد به استبدال (أو إلحاق الضرر) بـ JavaScript ، ولكنه بالأحرى تقنية مصاحبة ، لذلك افترض دائمًا أن تحقيق توافق ممتاز يمثل أولوية بالنسبة لي (بالنسبة لي يعني أيضًا: إمكانية التشغيل البيني ) مع الويب الحالي ، وهو هدف مرغوب فيه بشكل عام على الويب. أو كما تنص webassembly.org:

لسوء الحظ ، على مدار كل هذه المناقشات الساخنة ، كان لدي انطباع بأن فهمي لأهداف WebAssembly لا يتماشى مع ما يعمل من أجله خصومي الأكثر تأثيرًا داخل CG ، وهو ما لا يسعني إلا أن أراه كمحاولات لإنشاء حالة جديدة quo إلى حد كبير عوامل التوافق مع الويب. المشكلة الأولى التي أظهرها هذا الخلاف هي STRING i32 زوجًا لـ UTF-16LE في Interface Types (في عام 2017 ، في وقت الإنشاء باسم Host Bindings) ، حيث بعد عام ونصف من الصمت تم تبادل العديد من الحجج حول ما إذا كان UTF -8 ، وهو ترميز سلسلة غير متوافق إلى حد كبير مع واجهات برمجة تطبيقات الويب وجافا سكريبت ، يجب أن يكون في الواقع الترميز الوحيد المدعوم ، أو ما إذا كان من المفيد أيضًا مراعاة التوافق من البداية. في كتابي ، يجب أن يكون هذا أمرًا مفروغًا منه ، لذلك فوجئت جدًا بالسلسلة الهائلة من الحجج المتناقضة ، مما أدى بدوره إلى تأجيج الخلاف. تم حل المشكلة في النهاية (في الغالب) مع الإقرار بوجود العديد من اللغات التي تستخدم ترميز سلسلة يشبه جافا سكريبت والذي يجب أن ندعمه ، مما أدى بدوره إلى المفهوم الشامل لدمج المحول ، ومع ذلك لم يتم الاعتراف أبدًا بالتوافق مع واجهات برمجة تطبيقات الويب على وجه الخصوص مهمة. هناك بالتأكيد المزيد من النقاط غير الفنية التي يجب التحدث عنها في سياق هذه المشكلة ، لكنني أقترح تجنبها في الوقت الحالي والتركيز على اتجاه WebAssembly.

قضية أخرى مماثلة هي قصة GC للأوتار؟ في مقترح GC ، والذي لم يتوصل إلى حل حتى الآن ، وربما لا يلزم بالضرورة أيضًا إذا كان الهدف هو MVP يمكننا جميعًا الاتفاق عليه. ومع ذلك ، أشارت المناقشة حتى الآن أيضًا إلى وجود خلاف يتعين علينا حله في النهاية ، أي بمجرد استخدام GC بطريقة تتطلب إمكانية التشغيل البيني بين WebAssembly وواجهات برمجة تطبيقات الويب التي تتضمن سلاسل ، وربما تتضمن أيضًا رسمًا بيانيًا تعسفيًا للوحدة ، لذلك بشكل مثالي مع الحد الأدنى من التحويلات والنسخ. يظهر الخلاف العام أيضًا في قضية متابعة بخصوص قصة GC أفضل للمصفوفات؟ ، والتي تم تتبعها بسرعة للتشكيك في قدرتي وقيمة المشروع الذي أعمل عليه بدلاً من مناقشة القلق المطروح ، والذي أراه اليوم أكثر كنتيجة مؤسفة لسوء فهم طويل الأمد. إذا كان هناك أي شيء ، فإنه يؤكد أن هناك فرصة هنا للاصطفاف على أرضية مشتركة مرة أخرى.

لقد فوجئت أيضًا بالجهود الأخيرة لعدم السماح باستيراد مكرر؟ ، آلية مفيدة للتكامل مع اللغات الديناميكية مثل JavaScript حيث يكون التحميل الزائد بالتوقيعات المتعددة أمرًا شائعًا. دفعني التسرع في التصويت على الإزالة في نفس الاجتماع بعد العرض التقديمي إلى إثارة دهشتي على الأقل ، ولكن قد يكون هذا مجرد سوء فهم آخر أو خلاف حول كيفية عمل العملية.

لا أتحدث نيابة عن أي شخص ، لكن التصويت على القضايا كان جزءًا مفيدًا تاريخيًا من العملية لقياس آراء المجتمع ، ولن أقرأه على عجل للتصويت ، أكثر من استطلاع للتوجيه. إذا ألقيت نظرة على الملاحظات ، فقد قرر CG أننا بحاجة إلى مزيد من الاهتمام بالمشكلة وستظل مشكلة التصميم مكانًا لهذه المناقشة.

وبالمثل ، جئت مؤخرًا للتساؤل عما إذا كان WASI قد يتسبب في إلحاق الضرر بحالات استخدام Wasm على الويب؟ بالنسبة لي ، يبدو أن إنشاء حالة جديدة كأثر جانبي قبل أن تتاح الفرصة للجزء الأكثر تركيزًا على الويب من المجتمع لإيجاد حل يعزز التوافق مع الويب أكثر من التجزئة ، نظرًا لأن المقترحات ذات الصلة ليست بعيدة كافية. أنا شخصياً أعتبر الأولويات التي يتم إجراؤها هناك إشكالية للأسباب التي أثيرت في هذه القضية. ومن قبيل الصدفة ، تم دفع الجهود في WASI إلى الأمام من قبل أعضاء CG سابقًا الذين جادلوا ضد نقاطي في Interface Types ، وبينما لا يعني الارتباط بالضرورة السببية ، فقد قادني في النهاية إلى التساؤل عن الاتجاه العام لـ WebAssembly ، مما يؤدي بنا إلى هذه المشكلة.

تنص مبادئ تصميم WASI التي نظرت إليها جيدًا الآن ، صراحةً على أنها لا تقتصر على واجهات برمجة التطبيقات التي يسهل إعادة تعبئتها على الويب ، بينما تنص أيضًا صراحة على أن WASI يجب أن تعمل مع معايير الويب حيثما أمكن ذلك . كما أشار @ conrad-watt سابقًا ، هناك تمييز بين اللغة الأساسية والنظام البيئي ، وهي مساحة اسم يمكن للمضيفين ببساطة اختيار عدم تقديمها. WASI كنظام بيئي له أهداف تصميم مختلفة ، ويبدو أن إجبار توافق الويب على أن يكون أحد أهدافهم غير مثمر للمشكلات التي تحاول WASI حلها.

كما يجب أن يكون واضحًا الآن ، لقد أصبحت قلقة للغاية من أننا ، كمجتمع ، لا نقوم بما هو ضروري لضمان التوافق الممتاز مع الويب ، بينما نتسامح في نفس الوقت مع المقترحات الجديدة والتكنولوجيا ذات الصلة لكسر التوافق مع الويب أكثر من اللازم أو يؤثر عليها بشكل سلبي أو مباشر أو غير مباشر. لقد دفعني هذا إلى التساؤل ، على سبيل المثال ، ما إذا كان Wasm ، أو على الأقل نفسه في المستقبل ، ربما لا ينبغي أن يكون توصية W3C لأنه يضر بالتوافق مع الإصدارات السابقة قطعة أساسية واحدة في كل مرة ، وهو بالتأكيد استنتاج متطرف ، ولكنه سيكون بمثابة السؤال النهائي الذي يجب أن نطرحه عندما يزداد مستوى الخلاف أكثر ، على ما أعتقد.

يتكون المجتمع من العديد من الأشخاص الذين عملوا على معايير الويب أو استثمروا بشكل كبير في الويب. بينما أسمع مخاوفك ، لست متأكدًا من أن المستقبل مروع تمامًا. هل يمكنك إضافة أمثلة ملموسة حيث تم بالفعل اختراق التوافق مع الإصدارات السابقة بطريقة مفيدة؟

بناءً على هذه الخلفية ، أنتقل اليوم إلى CG مع طلب مناقشة الإضافة التالية إلى الأهداف العامة لـ WebAssembly من أجل تقليل الاحتكاك غير الضروري في المستقبل:

يعد التوافق مع Open Web Platform بشكل عام ، و Web APIs و JavaScript على وجه الخصوص ، أمرًا بالغ الأهمية لنجاح WebAssembly على المدى الطويل ، ويجب عدم المساس به إذا كان من الممكن تجنبه. يعتبر الشريط مرتفعًا بشكل خاص للمقترحات التي تعزز الوظائف التي لا تستهدف الويب بشكل أساسي ، حيث قد يكون هناك القليل من الحافز لعدم التأثير سلبًا على هذا الهدف.

هذا هو الجانب الأعلى من المستوى الذي كنت أدافع عنه ، باختصار ، وإذا تمكنا من الاتفاق عليه ، وقمنا فقط بتدوينه ، فإن معظم الاحتكاك في المناقشات أعلاه سيصبح (في الغالب) عفا عليه الزمن ، على الأقل بقدر ما أشعر بالقلق ، أثناء إعادة إيماني إلى العملية.

ما يمكن أن يعنيه هذا:

• أنواع الواجهة جيدة ، لكن تشفير سلسلة JS مهم بسبب التوافق ، وقد يكون الترويج لـ UTF-8 فوقه لتوفير ضغط لطيف أو ما شابه ذلك ، أو تبريره باتجاهات مزعومة ، مشكلة
• الخيوط ، SIMD ، i31ref وما إلى ذلك كلها جيدة ، لأنها غير مرتبطة وتضيف وظائف فقط ، ما لم تكن كذلك / لم تعد كذلك
• GC على ما يرام ، ولكن سيكون الدافع لإيجاد حل مناسب لقابلية التشغيل البيني في نهاية المطاف
• WASI جيد ، ولكن سيكون الدافع للنظر في بدائل لما هو في الأساس libc حاليًا قبل المضي قدمًا في مسار التجزئة
• يعد WASI-nn جيدًا ، ولكن سيكون لديه الدافع للتعاون على سبيل المثال مع Machine Learning for the Web CG

إذا اتضح أن CG لا يمكنها إيجاد إجماع حول جعل مثل هذه الفقرة رسمية ، أو إذا كانت التعديلات الرئيسية ضرورية ، فسأكون قلقًا للغاية بشأن مستقبل Wasm خاصةً في سياق كونها معيارًا للويب وأقترح إعادة - تقييم أهدافنا وما ننقله للعامة بمزيد من التفصيل. في هذه الحالة ، قد نرغب أيضًا في إجراء تصويت لإضفاء الشرعية على مثل هذا المسار ، على ما أعتقد.

اسمحوا لي أن أعرف أفكارك ، شكرا لك! :)

إن العودة إلى إضافة حواجز صريحة للدخول في شكل عملية لا تعمل بشكل جيد في الممارسة العملية ، وبالنظر إلى أن مخاوفك تتعلق بالمقترحات الموجودة بالفعل ، حتى لو كنا نعرف بالضبط مكان تضمين هذا النص من منظور عملية صارم هذا لن تطبق بأثر رجعي. تاريخيًا ، حاولنا الحفاظ على عملية تقديم العروض خفيفة الوزن لتشجيع التقدم إلى الأمام ، وعهدنا إلى CG لاتخاذ القرارات المنطقية. لا تصل إضافة حواجز العملية إلى حد بعيد إلا إذا كان الافتراض هو أن CG لا تعمل بحسن نية. لا أقول على الإطلاق أن هذا هو ما تعنيه ، فقط أن حواجز الدخول ليست طريقة جيدة بشكل خاص لمعالجة المخاوف التي أثيرت.

tlively يبدو أنني ضربت على وتر حساس في تعليقي السابق. يرجى الانتظار معي للحظة ، لأنني أعتقد أن التفكير في هذا بالكامل يمكن أن يكون ذا قيمة عند تجنب النتائج السيئة أو تقليل التوتر في المستقبل هو الهدف. على سبيل المثال ، يمكن أن يكون السيناريو المتطرف الافتراضي الأكثر دقة هو "ماذا لو قام الممثل المسؤول أيضًا عن المقترحات الأساسية بتأخير التقدم بها لإعطاء نتائج مجموعة فرعية ذات أهداف مختلفة وقتًا لتزدهر في النظام البيئي الأوسع - بينما لا يمكننا منع ذلك ، فهل يمكننا تريد تثبيطه؟ ". مثل ، لقد فكرت في هذا لفترة من الوقت ، لكني أريد أن أؤكد أن هذا كله افتراض وأن ذكره يخدم قضية أعلى. أنا فقط لا أريد أن أضعف اقتراحي في OP من خلال التراجع عن جانب قد يكون ذا صلة لفهم عملية تفكيري المؤدية إليه. قد تكون هذه معضلة أخرى ، على ما أعتقد ، وأنا أبذل قصارى جهدي لأكون محترمة بقدر ما أستطيع. على سبيل المثال ، حذفت ردي السابق الذي كان نصه "شكرًا للإشارة إلى هذا الأمر وكوني داعمًا للغاية ، اعتذاري" ، لأنني لم أكن واثقًا تمامًا من التراجع عما كان يدور في ذهني بعد التفكير في ما قد نفقده للمناقشة . آمل أن يكون هذا على ما يرام ، بالنظر إلى ما أعتقد أنه على المحك؟

dtig شكرًا جزيلاً على ردك الشامل. لقد جعلتني قراءته أكثر ثقة بشأن مستقبل WebAssembly ، كما جعلني أكثر ثقة في أن تجربتي حتى الآن ليست ممثلة لمجموعة CG ككل كما كنت أعتقد في البداية. تستند الأمثلة التي يمكنني تقديمها في الغالب إلى المناقشات داخل القضايا الفردية التي ربطتها في OP ، وليس كثيرًا على نشاط CG ككل كما أدرك الآن. إن عبارة "يجب أن يعمل WASI مع معايير الويب حيثما أمكن" هو أيضًا جانب أتفق معه بشدة ، وربما أسيء فهمه لأنه يبدو لي أنه قد تم نسبيته في الجملة التالية "حيث لا يكون ضروريًا" ، نظرًا لأن JavaScript ، وهو السياق ، هو معيار الويب هذا ، ولا يتطابق مع تجربتي حتى الآن في المشكلات ذات الصلة في WASI (راجع https://github.com/WebAssembly/WASI/issues/402 حيث تكون النتيجة واجهة تشبه سجل النظام). سأضطر إلى إعادة التفكير في الآثار المترتبة هنا قليلاً ، إذا كان ذلك جيدًا ، لكنني مهتم بمناقشة هذه النقطة ، ومن المحتمل أن أجادل في نقطة المستوى الأعلى بأن مبادئ تصميم WASI لا ينبغي أن تكون غير قابلة للتفاوض ، كما كان انطباعي عن ذلك. حتى الآن ، نظرًا لأن WASI يقع تحت مظلة WebAssembly لا يمنحه فقط حرية إنشاء واجهات برمجة تطبيقات جديدة ، ولكنه ينطوي أيضًا على مسؤولية بسبب التأثيرات غير المباشرة المحتملة (التي أود زيادة الوعي بها) على WebAssembly الأساسي.

أعتقد أن WASI ليس تصميمًا جيدًا. أولاً ، تجميع الويب المصمم للجهاز الظاهري للويب ، وتصميم بعض واجهات برمجة التطبيقات المتوافقة مع posix لا يتماشى مع اتجاه التطوير. ثانيًا ، تتمثل الطريقة الأفضل لتقديم واجهات برمجة التطبيقات لجهات خارجية في تحديد الواجهات (التفاعل بين مجالين) بحيث يمكن التحكم في عدد واجهات برمجة التطبيقات ويمكن أيضًا التحكم في الأمان.

قد يكون السيناريو المتطرف الافتراضي الأكثر دقة هو "ماذا لو قام الممثل المسؤول أيضًا عن المقترحات الأساسية بتأخير التقدم بها لإعطاء نتائج مجموعة فرعية ذات أهداف مختلفة وقتًا لتزدهر في النظام البيئي الأوسع - في حين أننا لا نستطيع منع ذلك ، فهل نريد تثبيط هو - هي؟"

أعتقد أنه إذا كان هناك خلاف داخل الاقتراح ، فيمكن للطرف المخالف عرض مخاوفه على CG ، التي لها سلطة على المقترحات. يتطلب الاعتماد الشحن في أحد التطبيقات ، لكنه لا يتطلب الشحن في جميع عمليات التنفيذ (أعتقد أن الرقم الثاني هو الرقم ، لكنني لم ألقي نظرة عليه منذ فترة). لست متأكدًا من كيفية تمكين هذا أي شخص من تأخير اقتراح ضد رغبات أي شخص آخر ، طالما أن هناك تطبيقات.

penzn للأسف ، لن نكون هنا إذا كانت العملية مثالية. على سبيل المثال ، قد ننظر إلى خلافي مع مبادئ تصميم WASI. لا أعرف كيفية التعامل مع هذه الأمور بشكل صحيح ، نظرًا لأن WASI مستقلة إلى حد كبير عن طريق التصميم ، والتي تعتبرها الأغلبية المعاصرة شيئًا جيدًا ، لذلك لا يمكن إثارة مخاوف الصورة الأكبر إلا في WASI نفسها ، ولكن بعد ذلك كان انطباعي أن إثارة المخاوف مع WASI في WASI من غير المرجح أن يؤدي إلى حل ، لأن معظمهم في WASI يريدون بطبيعة الحال أن تظل WASI على ما هي عليه ، وهو أمر مفهوم. لقد تم إرسالي مرة أخرى إلى Interface Types ، على سبيل المثال ، على الرغم من أنها نفس المجموعة وهم يعرفون المشكلات التي مررت بها هناك ، وفي كثير من الأحيان ما أشرت إليه هو "غير متوافق مع مبادئ تصميم WASI" وهذا كل شيء. لذلك حاولت تحديد مشكلة المستوى الأعلى ، والتي في رأيي تتلخص في إضفاء الشرعية على WASI بحيث تكاد تتماشى مع أهداف WebAssembly الأساسية ، بينما في نفس الوقت لا تتحمل مسؤولية أهداف WebAssembly الأساسية. لذا أقترح تكييف العملية ، لأنني إما لا أستطيع استخدام العملية ، أو لا أشعر بالتمكين للقيام بذلك.

يرجى الاطلاع على مناقشة أمان C API في اجتماع CG بتاريخ 2021-04-28 ، لقد كان موقفًا مشابهًا حيث لم يتم حل مخاوف مقدم العرض ضمن الاقتراح. بالطبع ، الاختلاف في حالة WASI هو أنه ليس اقتراحًا ، ولكن يجب أن تظل CG تتمتع بسلطة إجرائية. في حالة أمان C API ، كانت هناك مشكلات ملموسة أثيرت والتي كان على بطل الاقتراح قبولها بعد انحياز CG مع المنشق ، ومع ذلك أعتقد أنه يمكنك التقديم بدون تصويت في النهاية أيضًا.

أنا آسف ، لكني لا أرى كيف يمكن مقارنة "سلامة واجهة برمجة التطبيقات C" بمخاوف أكبر تتعلق بالصورة. هل يمكنك التفصيل؟ على سبيل المثال ، أشعر أن تقديم عرض تقديمي مؤيد للويب في WASI لن يؤدي إلا إلى زيادة الخلاف. كما قال dtig ، فإن القيام بذلك "يبدو أنه غير منتج للمشاكل التي يحاول WASI حلها".

في نقاش أمان C API ، كان هناك أيضًا خلاف على مستوى عالٍ حول الأهداف والاحتياجات (ما إذا كانت الفحوصات مطلوبة أم لا لواجهة برمجة التطبيقات للغة غير الآمنة) ، والتي تم حلها في مناقشة CG. هذا معيار مفتوح - تقديم المقترحات وبدء المناقشات هي الأدوات الوحيدة التي لدينا حقًا لتغييرها.

بعض الأفكار حول مشكلة النظام البيئي: أوافق على أن التجزئة بين واجهات برمجة تطبيقات الويب والخادم يمثل مخاطرة. مع إضافة WASI ، لدينا الآن مجموعتان من واجهات برمجة التطبيقات الموحدة لـ Wasm ، وبدون مسار واضح للتوحيد ، نظرًا لأنني شخصياً متشكك في أن المتصفحات ستتبنى WASI ونظراً لوجود WASI ، يبدو العكس غير مرجح أيضًا.

كان من الأفضل للويب لو أن WASI يركز على نقل واجهات برمجة تطبيقات الويب إلى الخادم. لكن هذا لا يعني أنه كان من الأفضل لوسم ككل. أقدر المقارنة مع Node.js وسجل واجهة برمجة التطبيقات هناك ، لكنني أعتقد أن الأمر يسير في كلا الاتجاهين: نعم ، كان من الجيد أن تستخدم Node.js المزيد من واجهات برمجة تطبيقات الويب ، ولكن ربما يرجع نجاح Node.js الهائل جزئيًا إلى إضافة واجهات برمجة التطبيقات التي يحتاجونها بغض النظر عن الويب. ربما يكون WASI ضروريًا لنجاح Wasm على الخادم - نظرًا لمدى اختلاف النظم البيئية للويب والخادم ، ربما يكون تجزئة واجهة برمجة التطبيقات أمرًا لا مفر منه.

هذا أحد الأسباب التي جعلتني شخصياً لم أنتقد الواسي عندما بدأت. في حين أنه من وجهة نظر الويب ليس هو الأمثل ، فقد يظل ضروريًا لنجاح Wasm على الخادم ، والذي قد يكون جيدًا لنجاح Wasm بشكل عام. (السبب الثاني هو أن نموذج WASI الأمني ​​مثير للاهتمام وقد يساعد أيضًا Wasm على الازدهار).

بشكل عام ، يتم توسيع Wasm بعدة طرق إلى جانب الويب والخادم ، مثل المكونات الإضافية وحلول وضع الحماية و blockchain وغيرها. كشخص يعمل في الغالب في منطقة واحدة ، لا أريد أن أنتقد الأشخاص الذين يعملون في مناطق أخرى. لا ينبغي أن نبطئ بعضنا البعض.

أعتقد أن الاستثناء الوحيد لذلك يجب أن يكون خطرًا جسيمًا حقًا ، من التجزئة أو غير ذلك. لا أرى مثل هذا الخطر حاليا. في حين أن وجود اثنين من واجهات برمجة التطبيقات القياسية يجعل بعض الأشياء محرجة وأقل مثالية ، يمكننا تعويض الخادم -> الويب بالفعل ، وفي النهاية سنكون قادرين على تنفيذ Web -> الخادم أيضًا الذي سيساعد. بالنسبة لمشكلات مثل السلاسل ، أرى أن عمليات الاستيراد المسبق تسمح باستخدام السلسلة الأمثل في نهاية المطاف على الويب - مما سيجعل أيضًا تجزئة واجهة برمجة التطبيقات في Wasm أكثر وضوحًا ، ولكن في هذه الحالة يكون موجودًا مسبقًا بسبب الاختلافات اللغوية التي لا يمكن تجاوزها. بشكل عام ، فإن المخاطر حقيقية ومزعجة ولكنها تبدو قابلة للإدارة ولا مفر منها.

الأفكار الجيدة ، kripken ، هذه تتماشى مع فهمي للبديل.

فيما يتعلق بمقارنة Node.js ، فإن ما كان يدور في ذهني على وجه الخصوص هو أشياء مثل Buffer مقابل Uint8Array ، والتي لا تزال مسؤولة عن الكثير من عمليات إعادة التعبئة (البطيئة) على الويب. أو الشيك global مقابل window الذي يمكن تجنبه في كل وحدة نمطية محمولة أخرى. أو TextDecoder لم يكن عالميًا لفترة من الوقت لتقليل وقت بدء التشغيل. أو لا يزال crypto.getRandomValues غير متوفر على مستوى العالم. أو كل المخاطر مع دعم ESM حتى اليوم. كنت أزعم أن Node.js كان من الممكن أن يكون أداؤه أفضل في بعض الأماكن ، في حين أن دعم fs وما إلى ذلك ربما كان أمرًا لا مفر منه.

في WASI ، يبدو أن الموقف مشابه ، حيث أننا سنحتاج على الأرجح إلى نظام ملفات WASI ، ولكن بعد ذلك توجد واجهات برمجة تطبيقات أخرى توفر وظائف مشتركة عبر الأنظمة البيئية ، وواجهات برمجة التطبيقات (API) الضرورية لإنشاء وحدة أساسية محمولة في المقام الأول ، حيث أعتقد أنه يمكننا القيام بعمل أفضل مما نتجه إليه حاليًا. تخيل على سبيل المثال وحدة تكتب للتحكّم عندما يحدث خطأ ما ، وتحصل على الوقت الحالي وما إلى ذلك ، حيث يبدو الاعتماد على متعدد التعبئة WASI (الكامل) مبالغًا فيه. أتخيل أن بعض الوحدات ستظل بحاجة إلى ملف متعدد مصاحب لنظام ملفات WASI (فقط) على الويب ، وأعتقد أنه يمكن التحكم فيه بالفعل. لا أعتقد أننا في وضع الكل أو لا شيء هنا ، ولكن هناك مجالًا كبيرًا للتعاون الذي سيؤتي ثماره في النهاية "لكن مبادئ التصميم". حجتي هي: إذا استطعنا ، فربما ينبغي لنا ذلك ، وإذا احتجنا إلى تكييف العملية قليلاً من أجلها ، فيجب علينا أيضًا.

فيما يتعلق بالاستيراد المسبق ، لست من أشد المعجبين بالاعتماد على هؤلاء في عملية التشغيل المتداخل الأساسي شخصيًا ، لأنني أعتقد أن السلاسل ضرورية جدًا لدرجة أن التجزئة على هذا المستوى ليس ما نريده في النهاية. على سبيل المثال ، ذكرت في مكان آخر أن الأنظمة البيئية التي تحتاج إلى قابلية النقل قد تتقارب في النهاية لاستخدام سلاسل JS ، ليس لأنه من الرائع القيام بذلك ، ولكن بسبب الضرورة المطلقة. أعتقد أن أولئك الذين اختلفوا معي سابقًا لن يكونوا سعداء جدًا بهذه النتيجة ، بما في ذلك أنا.

ربما يكون ذا صلة إلى حد ما في السياق ، مقتطف من آخر مشاركة مدونة لدينو مع إشارات مشرفة للتجزئة من جانب الخادم وقيمة الالتزام بواجهات برمجة تطبيقات المتصفح:

توسيع برمجة الويب خارج المتصفح ليس فكرة جديدة. في الواقع ، لقد فعلنا ذلك بنجاح معتدل في مشروعنا "Node.js". ولكن بعد أكثر من عقد من الزمان ، وجدنا أن JavaScript من جانب الخادم مجزأة بشكل ميؤوس منه ، ومرتبطة ارتباطًا وثيقًا بالبنية التحتية السيئة ، وتحكمها لجان بشكل لا رجعة فيه دون حافز للابتكار. نظرًا لأن النظام الأساسي للمتصفح يتحرك إلى الأمام بوتيرة سريعة ، فإن JavaScript من جانب الخادم أصبح في حالة ركود.

الدينو هو محاولتنا لبث حياة جديدة في هذا النظام البيئي. لتوفير نظام برمجة حديث ومنتج يلتزم بواجهات برمجة التطبيقات للمتصفح. نظام Deno ليس نظامًا مترابطًا ، بل هو عبارة عن مجموعة من التقنيات التي نعتقد أنه يمكن إعادة توظيفها في مجموعة متنوعة من الاحتياجات. لا تحتاج كل حالة استخدام لجافا سكريبت من جانب الخادم إلى الوصول إلى نظام الملفات ؛ تجعل بنيتنا التحتية من الممكن تجميع الارتباطات غير الضرورية. يتيح لنا ذلك إنشاء أوقات تشغيل مخصصة لتطبيقات مختلفة: واجهات المستخدم الرسومية ذات النمط الإلكتروني ، ووظائف Cloudflare على غرار العمال ، والبرمجة النصية المضمنة لقواعد البيانات ، وما إلى ذلك.

إنه بالطبع ليس هو نفسه تمامًا ، ولكن ربما لا يزال هناك شيء يمكن تعلمه من الدروس التي تعلموها.

بالتأكيد مقالة ذات صلة ، نعم. اقتباس رئيسي آخر منه:

نعتقد أن العديد من المطورين يفضلون طبقات تجريد الويب أولاً.

سبب آخر وراء أهمية تعديل الويب> الخادم (كما ذكرنا سابقًا).

ملاحظة جانبية: لقد رسمت عنصرًا أساسيًا لحل جزء من المشكلات التي أراها مع WASI والتجزئة على مستوى أساسي في الوقت نفسه ، باسم System Essentials for WebAssembly ، ولكني أرغب في معرفة ما إذا كان شيء مثل هذا يبدو جيدًا من قبل اقتراح أي شيء (لا تتردد في فتح قضية هناك). إذا رأى شخص ما قيمة في ذلك كما أفعل (أو حتى يريد المشاركة في البطولة / تقديم التوجيه) ، فأخبرني بذلك. إذا لم يكن الأمر كذلك ، فسأكون مهتمًا بأفكار بديلة تحقق تأثيرًا مشابهًا :)

من لمحة سريعة على مستندك ، تتكون قائمة "الأساسيات" بالكامل من _ قدرات النظام. إن توفيرها بشكل افتراضي يعني وجود قدرات محيطة ، وبالتالي من شأنه أن يقوض نموذج وضع الحماية الذي صمم Wasm بعناية لتأسيسه.

علاوة على ذلك ، لا يمكن توقع أن تكون أي من القدرات الموجودة في تلك القائمة متاحة عالميًا ، حتى عبر البيئات التي تستضيف Wasm اليوم. على سبيل المثال ، لا يتوفر الوقت الحالي (ناهيك عن التوقيت المحلي) ولا العشوائية ولا التسجيل في الأنظمة اللامركزية مثل blockchains.

إن توفيرها بشكل افتراضي يعني وجود إمكانات محيطة

ربما مثل وجود ذاكرة. لا يبدو مختلفًا تمامًا.

وبالتالي تقويض نموذج وضع الحماية الذي تم تصميمه بعناية لتأسيسه.

فقط إذا كانت الذاكرة ، أو عدم الحتمية على أجهزة مختلفة (FP ، SIMD المريحة) تعمل كذلك ، على ما أعتقد. لم أقصد ، ولا أعتقد أن الطبيب "يقوض" تصميم واسم الدقيق.

لا يمكن توقع توفر أي من الإمكانات الموجودة في هذه القائمة عالميًا

يعمل برنامج Wasm الثنائي على بعض الأجهزة مع بعض الأجهزة الافتراضية على بعض أنظمة التشغيل ، لذلك لن أوافق هنا. أعتقد أنه من المعقول توقع توفرها عالميًا ، على الرغم من أن حالات الاستخدام الخاصة قد ترغب في تقييد استخدامها.

على سبيل المثال ، لا يتوفر الوقت الحالي (ناهيك عن التوقيت المحلي) ، ولا العشوائية ، ولا التسجيل على الأنظمة اللامركزية مثل blockchains

قل blockchains على سبيل المثال. هذه عادةً لا تسمح بحساب الفاصلة العائمة اعتبارًا من اليوم ، وقد لا تسمح بالمثل بالحصول على الوقت أو تقرر التخلص من رسائل السجل ، لكن العقد لا تزال تعمل في بعض الأجهزة الافتراضية على بعض أنظمة التشغيل. أود أن أقول أيضًا أنه يعتمد على حالة الاستخدام الدقيقة لدفتر الأستاذ ، لذلك هناك حالات استخدام محتملة جدًا حيث لا تكون القيود ضرورية. لا أعتقد أن واسم يمكنه حل هذا بمعنى خالص على أي حال. نقطة أخرى هي أجهزة إنترنت الأشياء التي تحتوي على أقل من صفحة واحدة من الذاكرة ، مع تأثيرات مختلفة.

بشكل عام ، أعتقد أن محاربة التجزئة على هذا المستوى الأساسي أمر ذو قيمة ، ومن الواضح أنني مهتم بالتفكير في ذلك ، حتى لو كانت النتيجة شيئًا مختلفًا تمامًا عما هو مذكور في مستندي (أنا على ما يرام في التخلص منها) ، ولكن في النهاية يحقق شيئًا مشابهًا. مثل تسوية بناءة ومستنيرة. على هذا النحو ، أود أن يكون لديكم أفكارك حول كيفية تحقيق ذلك ، معًا ، بشكل شخصي أيضًا لأن ذلك سيجعلني أشعر أن أفكاري تعتبر ذات قيمة من قبل الأشخاص الذين أحبهم لخبرتهم التقنية.

على أي حال ، قد يكون من الأفضل نقل هذه المناقشة إلى ملف المستندي الخاص بي ، أو Discord ، أو البريد الإلكتروني ، أو الدردشة الصوتية. لذا يرجى القيام (أو الاتصال بي حيث يعمل بشكل أفضل) ، إذا كان هذا هو انطباعك أيضًا :)

أعتقد أن هناك قيمة في عدم وجود مواصفات WebAssembly الأساسية التي تفترض أي شيء يتعلق ببيئة التنفيذ ، بما في ذلك وجود نظام تشغيل أو مفاهيم محيطة للوقت أو التسجيل. لأي شيء يعتمد على الحالة أو يغيرها خارج دلالات Wasm الرسمية ، تحدد المواصفات الأساسية وظائف مستوردة على أنها فتحة هروب شاملة ، ولكنها بالطبع لا تحدد أن أي مجموعة معينة من الواردات سيتم توفيرها.

بشكل عام ، أعتقد أن محاربة التجزئة على هذا المستوى الأساسي أمر ذو قيمة

أعتقد أن هذا هو لب الخلاف حول هذا الموضوع. أنا شخصياً أشعر بقوة أنه يجب ألا يكون الهدف من مواصفات Core Wasm هو محاولة توفير نظام بيئي موحد ، ولكن يجب أن تحاول توفير تجريد محمول (وفعال) للحساب الخالص قدر الإمكان. على سبيل القياس ، لا تحاول X86 ولا ARM توفير أنظمة بيئية موحدة (أو حتى ABIs موحدة) ؛ هذا يُترك لطبقة التجريد الخاصة بنظام التشغيل الموجودة فوقها ، وأعتقد أن هذا النموذج مناسب لـ WebAssembly أيضًا.

ومع ذلك ، من الواضح أن تجنب تجزئة النظام البيئي حيثما أمكن ذلك أمر ذو قيمة ، ولكن أعتقد أنه يجب أن يتم ذلك في طبقة فوق Core Wasm. المرشح الواضح لطبقة توحيد النظام البيئي هو WASI. هل ستنجح إذا تم توفير الإمكانات الأساسية التي حددتها بواسطة وحدة WASI المصممة خصيصًا للعمل مع الحد الأدنى من الغراء داخل وخارج الويب؟ أين تقصر مرافق WASI الحالية للوقت والعشوائية؟

ربما هذا هو المطلوب: مجموعة موحدة من عمليات الاستيراد الاختيارية ؛ متوفر في الويب ، ومعظم أنظمة WASI (لأنها اختيارية ، وقد يعمل WASI في بيئة مضمنة مقيدة على سبيل المثال) ، وأي أماكن قد توفر - اختياريًا - عمليات الاستيراد القياسية.

في الويب ، سيكون الأمر كما لو أن كود JS اللاصق قد مررهم ، لكن لا ، النظام مررها ولم يكن مطور JS مضطرًا لفعل أي شيء ، أو كان عليه ببساطة سردها بالاسم لاختيار أي منها تتوفر.

يمكن لمطوري الويب أن يعتبروا وجود بعض الواردات (أو يتم اختيارها من جانب JS) أمرًا مفروغًا منه ، في حين أن هذا لا يجبر Wasm نفسه على استخدامه في اللغة.

قد لا توفر بيئة blockchain الواردات (الاختيارية) على سبيل المثال.

يجب أن يكون المستخدم مسؤولاً عن معرفة البيئة التي يتم تشغيلها فيها وما هي الواردات الموثقة لتكون متاحة.

قد يعني هذا عدم الحاجة إلى تبديل المترجم لإخراج استدعاءات API مختلفة.

سيكون WASI شيئين: مزود للواردات القياسية ، ومزود للواردات المتخصصة للخادم فقط.

أعتقد أن مشكلة توفير عمليات الاستيراد القياسية على الويب دون أي JS هي مشكلة مختلفة قليلاً (ولكن dcodeIO ، أخبرني إذا كنت لا توافق). حتى مع وجود مجموعة قياسية من الواردات للاستخدام داخل وخارج الويب ، فإن JS API الحالية ستظل تتطلب كتابة JS لتجميع الوحدة النمطية وإنشاء مثيل لها ، وبالتالي فإن الفائدة الهامشية لمطوري الويب من السماح لبعض الواردات ضمنيًا ستكون صغيرة. بالنظر إلى مجموعة قياسية من الواردات ، قد يكون من المنطقي أن يتم توفيرها ضمنيًا من خلال شيء مثل اقتراح تكامل ESM ، ولكن المشكلة هنا هي أنه ليس لدينا مثل هذه المجموعة القياسية من الواردات حتى الآن.

dcodeIO

أعتقد أن فكرة System Essentials مثيرة للاهتمام ، لكني لا أتفق مع معيار جديد لهم. على النحو الأمثل ، يمكنهم الانتقال إلى WASI (كما قال tlively ) ، أو أن يكونوا واجهات برمجة تطبيقات الويب.

حول واجهات برمجة تطبيقات الويب: نقطة عادلة في الارتباط حول الحصول على المنطقة الزمنية التي تتطلب كائن تاريخ جديد. هذا مرهق في الوسم. ولكن هذا ممكن مع JS Reflect API ( Reflect.construct على وجه التحديد). يمكننا إضافة المزيد من واجهات برمجة التطبيقات مثل JS أو جانب واجهة برمجة تطبيقات Wasm JS حسب الحاجة. لا يزال يتعين الإعلان عن عمليات الاستيراد ، ولكن يجب أن تكون تكلفة حجم الرمز في حدها الأدنى.

حول واجهات برمجة تطبيقات WASI ، أعتقد بقوة أننا بحاجة إلى بذل المزيد من الجهد لسد فجوة الويب / الواسي. إن إضافة المزيد من واجهات برمجة التطبيقات الملائمة للويب إلى WASI أمر منطقي بالنسبة لي شخصيًا - ربما يشبه أساسيات النظام. لقد وصفت اتجاهًا محتملاً آخر الشهر الماضي وعرضت رسم تفاصيل محددة إذا كان هناك اهتمام ، لكنني لم أتلق ردًا من أفراد WASI حتى الآن. سيكون هناك ترحيب كبير ردود الفعل!

الجانب الحاسم بالنسبة لي هو أنه لا ينبغي أن يكون هناك رمز لاصق ضروري للوظائف الأساسية على الويب ، على التوالي ، الوظائف الشائعة على / خارج الويب ، حيث أعتقد أن النظام البيئي الذي يعتمد على polyfill الإلزامي للوظائف الأساسية للغاية ليس ما يجب أن نسعى إليه بالنسبة. آمل أيضًا أن نتمكن من العثور على شيء يعمل في كلا الاتجاهين ، من خلال عدم طلب polyfill على الويب ولا في WASI ، لتحقيق ربح للطرفين (على الرغم من أنه قد يكون ملء واجهات برمجة تطبيقات الويب خارج الويب مشكلة أقل - لكنني يفضل القيام بشيء لكليهما).

هذا هو المكان الذي تأتي منه فكرة تعليمات "أساسيات النظام" التي تفتقر إليها إلى حد ما ، والتي تستند في الغالب إلى ملاحظتي حتى الآن أن إضافة مساحة اسم استيراد ربما لن تحدث في المتصفحات لأسباب تم طرحها سابقًا ، لذلك كان حدسي هو أن التعليمات ربما قد تكون في الواقع أقل إشكالية ، على الرغم من وجود حجج جيدة ضد. أنا أتفق مع نقاطك حول الحفاظ على Wasm "core" ، وآمل أن يكون هناك شيء أفضل يمكننا القيام به على رأس Wasm الأساسي الذي يعمل مع كل من Web + WASI.

على هذا النحو ، أنا لست مرتبطًا بشكل خاص بفكرتي الخاصة ، وسأكون سعيدًا بأي شيء يحدد مربعات [x] يلغي الرمز اللاصق ، سواء كان ذلك عبر الإرشادات ، أو مساحة اسم استيراد شائعة على + خارج الويب (WASI أم لا) ، أو بشكل غير مباشر عن طريق تكامل ESM ودعم جزء منه خارج الويب ، بحيث نحقق في نهاية المطاف تجزئة أقل [x] (تعمل الوحدة نفسها على الويب وخارجه على حد سواء بدون تعبئة عند استخدام الوظائف المشتركة فقط ؛ رسم الخط في نظام الملفات و DOM ، والتي هي بالأحرى خاصة بالبيئة). هل هذا منطقي؟ :)

فكرة أخرى: ربما تكون محادثتنا مفيدة لتوضيح فكرة اللغات الفرعية - قل "ملفًا شخصيًا" لـ "web + wasi" أو شيء من هذا القبيل؟ قد يتلخص بعد ذلك في توحيد التقاطع بين سطح واجهة برمجة التطبيقات للغة الفرعية.

أيضًا ، مع فتح هذه المشكلة منذ ما يقرب من شهر حتى الآن ، وللأسف لا يكاد أي من أفراد تكنولوجيا المعلومات / الواسى الذين يتدخلون لتحسين الوضع ، قررت أن أحاول نفسي في تحليل الصراع fwiw.

أريد أن أؤكد أن ما يلي شخصي للغاية ولا يمثل حقًا سوى النموذج العقلي الناشئ لمنظر واسم. لا شيء من ذلك يشير إلى أن أي شخص يفعل شيئًا سيئًا ، فقط أن هناك نقاط تركيز مختلفة ، وهذا أمر طبيعي. يرجى إعلامي إذا كنت تشعر بأنك تعامل بشكل غير عادل ، وهذا ليس في نيتي ، وسأقوم بالتصحيح أو الحذف.

كان هدفي هو تحديد المحاذاة ، أو عدم وجودها ، بين لاعبي Wasm ، فيما يتعلق بجعل Wasm أكثر ثراءً ، أي تضمين المزيد من الميزات وحالات الاستخدام ، على التوالي ، إبقائها نقية ، أي الضغط على نقطة الحد الأدنى من ISA ، مع دمج أيضًا ركز على جوانب معينة من العملة ، هنا مهتم بشكل أساسي بتشغيل Wasm على منصة الويب على التوالي على الحافة أو داخل Blockchain ، غالبًا بمتطلبات مختلفة جدًا.

• المتصفح: خدمة منصة الويب ، وهي غنية بطبيعتها. "نظام تشغيل سطح المكتب الجديد" إذا جاز التعبير.
• الخادم: مجردة نسبيًا بطبيعتها كما في "أحضر أغراضك الخاصة". محايد.
• البحث: يريد جعل Wasm مفيدًا للجميع ، ما لم يكن مرتبطًا بممثل آخر.
• Google: ركز على نقل الأشياء إلى الويب وجعلها سريعة ؛ هل توافق على مراعاة احتياجات الآخرين طالما أنها لا تضر باحتياجاتهم؟
• Dfinity: الكل في Blockchain ؛ يحتاج إلى بعض سمات الثراء على ما يبدو ؛ ولكن كلما زاد عدد العظام كلما كان ذلك أفضل؟
• بسرعة: التركيز على الحافة ؛ Lean / الحد الأدنى من VM أمر بالغ الأهمية لمنتجهم ؛ مسؤول بشكل فعال عن تكنولوجيا المعلومات / الواسي؟
• Apple: موافق على ما يصلح للويب ؛ لست متحمسًا بالضرورة للتنافس مع متجر التطبيقات؟
• AssemblyScript: يريد التطبيق العملي في العالم الحقيقي ؛ يميل إلى الويب ولكنه غامض إلى حد ما بسبب أصحاب المصلحة على Edge / BC؟
• إنتل ؟: ليس هناك الكثير من العلامات حتى الآن ؛ هل أنت مهتم بالحساب الفعال؟
• Redhat ؟: ليس هناك الكثير من العلامات حتى الآن ؛ هل أنت مهتم في الغالب بالبنية التحتية؟
• مايكروسوفت ؟: ليس هناك الكثير من العلامات حتى الآن ؛ NET على الويب وفي النهاية في كل مكان؟
• موزيلا ؟: غير موجود؟

في حين أن هذا خطأ على الأرجح على عدة مستويات ، فقد وجدت أنه يوضح نموذجي العقلي جيدًا نسبيًا. لقد رسمت أيضًا سطرًا حيث يمكنني اعتبار "الويب في WebAssembly" من توقعاتي ، ولكن هذا أمر قابل للجدل مرة أخرى. إذا كان هناك أي شيء ، آمل أن يساعد في فهم من أين أتيت ولماذا تكوّن لدي انطباع بأن شيئًا ما معطل في Wasm-land ، مع تسليط بعض الضوء أيضًا على الموقف لأولئك الذين يهتمون بنظري المكثف للقضية ولكن قد لا يكون على علم بكل التفاصيل التي حدثت. خذ ، ولكن مع حبة ملح :)

بنس واحد ... أنا مندهش حقًا من حدوث هذه المحادثة. لطالما كانت فكرة سيئة أن تسمح WebAssembly بتحديد نطاقها من خلال أي حالات استخدام صادفها المستخدمون الأوائل.

يحتاج الويب WebAssembly بطريقة لا يفعلها أي نظام أساسي آخر ، لأن الويب يجب أن يقيد ما يمكن لمطوريه القيام به ، خاصة على مستوى WebAssembly.

إذا ذهب WebAssembly في اتجاه لا يحبه عمال المناجم المشفرة ، فيمكنهم تفكيكه أو أي شيء آخر. إنه ليس شيئًا نحتاج إلى الاهتمام به عند تصميم معايير الويب. كل شخص آخر لديه سيطرة كاملة على النظام الأساسي الأساسي. على الويب ، لدينا فقط النظام الأساسي الذي قدمناه لنا ، وبمجرد أن يصبح معيارًا ، فإننا عالقون فيه إلى الأبد.

يجب أن يكون WASI متشعبًا للقيام بأمر خاص به ، ويجب أن يكون للويب جهاز افتراضي خاص به تم تحسينه بالكامل للمتصفح ، حصريًا وعلى وجه التحديد.

لطالما كانت فكرة سيئة أن تسمح WebAssembly بتحديد نطاقها من خلال أي حالات استخدام صادفها المستخدمون الأوائل.

في الواقع ، يتم تحديد نطاقه بواسطة CG ، والذي يمكن أن ينضم إليه أي شخص ، بما في ذلك أنت. هناك ، يصوت الناس على الاتجاه ، والذي يمكن أن يتأثر إذا كنت ترغب في قضاء بعض الوقت في أن تكون نشطًا فيه ، ويقدم حججًا تقنية مدروسة جيدًا.

يمكن لأي شخص بالفعل أن يتفرع Wasm إذا أراد ذلك ، ولكن هناك الكثير من المزايا لنظام بيئي مشترك ، لذلك هذا ما تسعى إليه معظم الأطراف المهتمة.

إن تمكن كل شخص من الانضمام إلى CG يعني أنه لا يمكنك منع الأشخاص الذين لا يهتمون بالويب من الانضمام ، كما أخشى.

أنا مندهش حقًا من حدوث هذه المحادثة. لطالما كانت فكرة سيئة أن تسمح WebAssembly بتحديد نطاقها من خلال أي حالات استخدام صادفها المستخدمون الأوائل.
...
يجب أن تتشعب WASI للقيام بأشياء خاصة بها

WASI _is_ تقوم بعملها الخاص ؛ إنها مساحة اسم استيراد. لم يتم توحيدها على نفس مستوى ميزات لغة WebAssembly. هل الاقتراح بضرورة إعلان ميزات غير الويب خارج النطاق وعدم السماح بحدوث مواصفات WASI تحت المظلة الاسمية لمجموعة المجتمع؟ ما الذي يمكن أن يحققه ذلك من حيث منع التفتت؟

هناك ميزة في التحقق مما إذا كانت أجزاء معينة من WASI يمكن تعديلها لتكون أكثر وميضًا بدقة (سواء Web-> WASI أو WASI-> Web كما هو موضح هنا kripken ) ، ولكن حتى في أسوأ الحالات ، ينتهي بنا الأمر مع واجهة برمجة تطبيقات لا يمكن استيرادها على الويب ، تمامًا كما لو تم إكمال WASI كمشروع تابع لجهة خارجية لوقت تشغيل بخلاف الويب.

مرة أخرى ، عند قراءة المشكلات المرتبطة dcodeIO ، لا أرى أي شخص يعتقد أن الويب ليس مهمًا لـ WebAssembly. كل ما أراه هو أن الناس يختلفون (أحيانًا بشكل غير مزخرف) حول الميزات / خرائط الطريق لحل احتكاكات interop محددة جدًا مثل تشفير السلسلة. أعتقد اعتقادًا راسخًا أنه من الخطأ وصف هذه الخلافات الفنية كدليل على صراع على السلطة بين الويب وغير الويب ، وأن القيام بذلك لن يؤدي إلى أي نتائج إيجابية.

لا أراها على أنها صراع على السلطة ، بقدر ما أراها قضية ذات نطاق واسع للغاية وفاعلية ذات نهاية مفتوحة. تعد شبكة الويب العالمية مهمة بما يكفي للحصول على جهاز افتراضي خاص بها ، بمواصفاتها ومعاييرها ، وفقًا لشروطها الخاصة ، وباستخدام التسميات الخاصة بها. أدت محاولة جعل كل شيء عامًا وتجريديًا إلى مواصفات وتوثيق ومحادثات غير مألوفة وغالبًا ما تكون غريبة على مطوري الويب.

لكي نكون واضحين ، فإن قضية الواصي كمشروع رسمي هي مسألة رمزية بحتة. لا يحدث أي فرق تقني ، لكن حالته توضح أن الويب يستخدم WebAssembly ، ولكنه ليس تقنية تم إنشاؤها بواسطة الويب ومن أجله.

لا أراه على أنه صراع على السلطة ...

@ 7ombie اعتذارًا ، كان الهدف من فقرتي الأخيرة هو التعليق بشكل أساسي على الرسم التخطيطي أعلاه لـ "الصراع".

أدت محاولة جعل كل شيء عامًا وتجريديًا إلى مواصفات وتوثيق ومحادثات غير مألوفة وغالبًا ما تكون غريبة على مطوري الويب.

أوافق على أن بعض التوقعات التقنية حول أنواع الواجهة على وجه التحديد أصبحت مقصورة على فئة معينة. هناك بالتأكيد مساحة في CG للمحادثات مثل "لماذا أنواع الواجهة بدلاً من أنواع السلاسل من الدرجة الأولى" ، ونحن نعتمد على مطوري الويب المتمركزين مثل dcodeIO يشاركون بآرائهم ومخاوفهم من أجل الحفاظ على العملية تعمل. لقد شعرت بالفزع من الطريقة التي انتهت بها المحادثة الأخيرة حول هذا الموضوع ، وآمل أن نتمكن من القيام بعمل أفضل في المستقبل.

فهمت ، @ كونراد وات. لم أر تلك المحادثة ، لكن من ناحيتي ، لا أرغب في اللعب في Web Vs. عقلية غير الويب ، أو أي شيء من هذا القبيل. أنا ببساطة أشارك قبضتي الشخصية على التكنولوجيا التي أنا سعيد جدًا بها بشكل عام ومتحمس لها وممتن لها.

كانت تعليقاتي السابقة انتقادية وصريحة للغاية ، لكني كنت مجرد عرضية. أنا لست مستاء.

@ كونراد وات وآخرون. من المحتمل أن يصبح الوصف الفني لأنواع الواجهة أكثر سرية قبل أن يصبح أقل في المستقبل القريب. على سبيل التفسير ، فإن الكثير من هذا مدفوع بالرغبة في الجمع بين إعادة الاستخدام والصرامة.

أود التأكيد على أنني أرى أيضًا قيمة في التعاون (مع WASI وآخرين) بقدر ما نستطيع بشكل معقول ، ومن ثم كنت أقترح البحث في الحلول التي تؤدي إلى إمكانية النقل بين الأنظمة البيئية بطريقة تغطي التقاطعات ، بما في ذلك المكان نرسم الخط حاليًا (DOM ، نظام الملفات). أدرك أن ما أقترحه قد يكون صعبًا ، أو أنه قد تكون هناك طرق أفضل لتحقيق شيء مشابه (أخبرني! :)). إنه فقط هذا (لأقتبس نفسي في OP)

لقد أصبحت قلقة للغاية لأننا ، كمجتمع ، لا نقوم بما هو ضروري لضمان التوافق الممتاز مع الويب ، بينما نتسامح في نفس الوقت مع المقترحات الجديدة والتقنيات ذات الصلة لكسر التوافق مع الويب كثيرًا ، أو التأثير عليه بطريقة أخرى بشكل سلبي أو مباشر أو غير مباشر.

قادني إلى اقتراح إعادة تقييم أهدافنا بطريقة أو بأخرى من خلال توضيح ذلك

يعد التوافق مع Open Web Platform بشكل عام ، و Web APIs و JavaScript على وجه الخصوص ، أمرًا بالغ الأهمية لنجاح WebAssembly على المدى الطويل ، ويجب عدم المساس به إذا كان من الممكن تجنبه. يعتبر الشريط مرتفعًا بشكل خاص للمقترحات التي تعزز الوظائف التي لا تستهدف الويب بشكل أساسي ، حيث قد يكون هناك القليل من الحافز لعدم التأثير سلبًا على هذا الهدف.

أنا لست مرتبطًا بجعل هذا مطلبًا للمقترحات (كما تم التلميح إلى أن هذا قد يصبح) بعد الآن كما كنت في OP ، حيث أتفق مع العديد من النقاط التي تم طرحها ، لكنني ما زلت أقدر الجهد المركز الذي يغيرنا بشكل فعال في هذا الاتجاه.

dcodeIO ، ما هو عنصر المناقشة المحتمل في تحليل النزاع الخاص بك ، هل تحتاج جميع الشركات التي أدرجتها إلى الكشف عن خططها ومقارنتها؟ هل تعتقد أن هذا ممكن وما الذي سيحققه؟

بينما لا يمكنني التعليق حقًا على أي من الشركات في مخططك ، أعتقد أن مقارنتها بهذا الشكل مضلل ، حيث لا يوجد كيان واحد قادر على تغيير المعيار بنفسه دون موافقة الآخرين. أجد أيضًا أن محور الرسم البياني غير موضوعي ومربك. على سبيل المثال ، يجب أن يكون تشغيل الحوسبة (دعنا نقول التقديم أو NN) في wasm على الويب "edge" ، نظرًا لأنه ينقل الحساب لأسفل من "السحابة" ، ولكن بعد ذلك يجب أن يكون أيضًا "ويب" ، نظرًا لأن هذا جزء مهم من الويب التفاعلي الآن (وبالتأكيد ليس "خادم" ، لأنه يعمل على جهاز العميل). البعد الآخر هو IMO أكثر ذاتية ، حيث أن النقاء والغنى في تعريفك هما مصطلحان نسبيان. مثال - هناك مناقشة طويلة الأمد بالفعل حول قيود تدفق التحكم مدفوعة باتفاقيات استدعاء Go. اعتمادًا على من تسأل ، ستُنظر إلى هذه القيود على أنها ميزة مفيدة أو غير ضرورية ، والتي أعتقد أنها ستؤثر على المكان الذي سيضع فيه هذا الشخص المناقشة على محور "الثراء مقابل النقي".

لطرح سؤال مباشر ، هل يتم تحديد الاتجاه البعيد المدى لـ WebAssembly بواسطة من يتبناه؟ على سبيل المثال ، إذا كان تبني مطوري الويب على المدى الطويل منخفضًا ، ولكن كان هناك لاعبون صناعيون كبار يستثمرون المليارات في استخدام WebAssembly لشيء لا علاقة له بالويب ، فهل ستأخذ احتياجاتهم الأولوية في النهاية؟

لطرح سؤال مباشر ، هل يتم تحديد الاتجاه البعيد المدى لـ WebAssembly بواسطة من يتبناه؟ على سبيل المثال ، إذا كان تبني مطوري الويب على المدى الطويل منخفضًا ، ولكن كان هناك لاعبون صناعيون كبار يستثمرون المليارات في استخدام WebAssembly لشيء لا علاقة له بالويب ، فهل ستأخذ احتياجاتهم الأولوية في النهاية؟

نحن معيار يحركه المجتمع / الإجماع. لا فائدة كبيرة في التفكير في هذه المواقف الافتراضية ، لأنه في الأساس لا يمكن الاحتراز منها بأي نوع من الإجراءات الرسمية. مرحبًا بكم في القلق الوجودي من بناء المجتمع / الإجماع.

نعم ، إذا كان الأشخاص الوحيدون الذين اهتموا بواسم هم مهندسو حوسبة متطورون ، فمن المحتمل أن اللغة ستقود في هذا الاتجاه. في هذا السيناريو ، حتى لو تمكنا بطريقة ما من نقش مبدأ مفاده أن الميزات المتوافقة مع الويب فقط يمكن توحيدها في CG ، فسيؤدي ذلك فقط إلى شوكة ، أو عدم وجود أي شخص يعمل على اللغة.

لكي أكون واضحًا ، أنا لا أعتقد مطلقًا أن هذا هو الوضع الذي نحن فيه. على المرء إما أن يثق في أن مصالح الويب يتم تمثيلها بشكل كافٍ من قبل أعضاء CG ، أو أن يشارك نفسه.

انظر ، هذا شيء لا أفهمه. من الواضح أن الهدف هو إنتاج معيار ويب في النهاية ، تحت مظلة W3C ، والذي يحتوي على مبادئ وقيم واضحة للغاية والكثير من الخبرة من تاريخ طويل من التحديات المماثلة. لا أرى كيف أن الويب يقود وكل شخص لديه مفترق يتماشى مع ما يبتكره الناس على الويب ، إذا كان هذا ما يريدون ، سيكون أسوأ. لذا ، نعم ، أقترح إنشاء WebAssembly للويب أولاً ، ولكل شيء آخر ثانيًا ، لأن العكس هو موقف لا يطاق إذا كانت تجربتي حتى الآن تستحق شيئًا ما. أيا كان ما يتطلبه ذلك ، يجب أن نفكر فيه ونتحدث عنه ، لأن هذا هو السبب الجذري للمشكلة على ما أعتقد.

كما قلت أعلاه ، بينما أوافق على أن الويب يجب أن يكون أولوية لـ WebAssembly ، لا أعتقد أن الخلافات الفنية التي كنت تواجهها مع أعضاء CG الآخرين ترجع أساسًا إلى انقسام فئوي بين الويب وليس الويب . هناك أسباب تجعل الأشخاص الذين يركزون على الويب فقط يرغبون في البحث عن بدائل للعديد من مقترحاتك ، ولا يجب أن تفسر هذا على أنه دليل على أن الأشخاص الذين يختلفون معك لا يهتمون بالويب.

لن تكون WASI من مواصفات W3C ، ولن تتداخل مع إنتاجنا لمواصفات W3C WebAssembly. إعلان أنه لا ينبغي تطوير WASI في إطار CG لأنه "ليس على الويب" لن يؤدي إلى تحويل الأشخاص المعنيين انتباههم إلى الويب. سيؤدي ذلك فقط إلى إغلاق خطوط الاتصال والتعاون القيّمة ، والتي قد تسمح لنا (على سبيل المثال) بالعثور على تداخلات مع بعض واجهات برمجة التطبيقات الافتراضية الملائمة للويب.

نقاط عادلة ، لكننا نختلف بشكل أساسي هناك ، إذ لا يمكنني التوفيق بين وجهة نظرك وكل ما مررت به. أعتقد أن هناك مؤشرات واضحة جدًا بالفعل على أن المشكلة موجودة ويجب معالجتها بدلاً من إخباري باستمرار أنه لا يوجد شيء يمكننا القيام به حيال ذلك. بالنسبة لي ، يبدو هذا سخيفًا ، لدرجة أن الناس يجب أن يخجلوا مما يفعلونه بـ WebAssembly ، الذي كان ذات مرة النجم الأكثر سطوعًا بين معايير الويب الذي من الواضح أنه لا يرقى إلى ما كان عليه في السابق.

أعتقد أن هناك مؤشرات واضحة جدًا بالفعل على أن المشكلة موجودة ويجب معالجتها بدلاً من إخباري باستمرار أنه لا يوجد شيء يمكننا القيام به حيال ذلك.

أعتقد أننا فشلنا في فهم المشكلة ، بدلاً من أن نقرر أنه لا يمكن فعل أي شيء حيالها. هناك اهتمام واضح بتحسين WASI أو أنواع الواجهات ، لكن لا يبدو أن هناك إجماعًا حول تلك التي تكون معطلة أو مخطئة بشكل أساسي.

شكرًا لك على حل المشكلة :) أريد أن أعتذر عن الانهيار الذي أصابني هنا ، والذي لم يكن جيدًا وأتوقع أفضل بكثير من نفسي. أرغب في مواصلة الانخراط مع المجموعة ، بما في ذلك مناقشة هذه المسألة المهمة (كما أعتقد) ، وآمل أن أوضح أنني أستطيع القيام بذلك بطريقة بناءة.

كبداية ، لقد اقترحت عرضًا تقديميًا حول مخاوفي بشأن ترميز السلسلة ، وحيث أعتقد أنه مناسب للخطوات التالية في أنواع الواجهة على التوالي ، التطوير الأحدث نحو نموذج مكون. وفي هذه العملية ، قررنا في النهاية تجربة تنسيق جديد لعرض تقديمي مسجل مسبقًا ، مع تحديد موعد المناقشة في اجتماع الفيديو CG في 22 يونيو. يمكن العثور على التسجيل في المشكلة المصاحبة المرتبطة مباشرة فوق هذا التعليق ، وآمل أن يساعد في توفير الخلفية اللازمة بطريقة أكثر تكثيفًا وبناءة.

إذا كان بإمكاني تقديم اقتراح لطيف: إذا قام شخص ما بإعادة تجميع الأجزاء غير WASM من شفرة مصدر متصفح الويب في Binaryen أو Rust ، مع استهداف WASI على سطح المكتب ، فهل يكفي القول أن معظم المستعرض هو فقط حشو كبير أم أنه سيقلب الجدل إلى الداخل على نفسه ، ويسبب انهيارًا كارثيًا ويحول الأرض إلى ثقب أسود؟

في ملاحظة جادة: IIRC ، بدأ الويب كوثيقة ارتباط تشعبي لدليل هاتف السير Tim Berners-Lee في CERN. لقد تجاوز الويب نفسه كل التوقعات بما في ذلك تلك المتعلقة بالتعقيد واستهلاك الذاكرة. لقد تطور متصفح الويب من كونه عارض مستندات إلى وسيط نشر كامل. هذا هو ميزة الزحف.

WASI ، كبيئة برمجة ، لديها القدرة على إعادة تقنيات الويب إلى جذورها كفرع لعلوم الكمبيوتر حيث يتم دمج النشر والتفاعل. منذ متى يجب أن تعمل غرف الدردشة في متصفح لتكون تقنية ويب؟ IRC ، بروتوكول الدردشة الأصلي ، كان موجودًا لفترة أطول من متصفح الويب على أي حال. وبالمثل ، فإن SMTP يسبق WWW وكذلك يفعل FTP. الإنترنت أكبر من مجرد الويب وهذا هو ما كان من المفترض أن يكون عليه.