الخلاصة

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

الإصلاح على الخادم، والعطل القديم على الشاشة

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

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

قائمة صريحة بدل الأمل في ذاكرة المتصفح

قدمت مذكرة W3C في مايو 2008 المشكلة من منظور المستخدم: يريد فتح البريد أو التقويم أو العمل على مستند حتى خارج الاتصال. ذاكرة HTTP العامة قد لا تحتفظ بكل ملفات التطبيق. لذلك تشير خاصية manifest في عنصر html إلى ملف من النوع text/cache-manifest يحدد الموارد التي ينبغي حفظها. ويحدد قسم NETWORK: الطلبات التي يجب أن تذهب إلى الشبكة.

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

يمنع هذا المنطق تركيب تطبيق نصفه جديد ونصفه مفقود. ويخلق في الوقت نفسه حاجزين أمام الإصلاح. تغيير main.js من دون تغيير البيان يترك النسخة القديمة. تغيير البيان مع غياب ملف مطلوب يتركها أيضاً. أصبح سؤال «هل أصلحنا الخادم؟» مختلفاً عن «هل رأى القارئ الإصلاح؟».

بيان لا يتحرك، وبيان لا يكف عن الحركة

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

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

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

Chrome حدد طريق الخروج

وضعت إرشادات Chrome لعام 2020 جدولاً مرحلياً للتوقف. أوقف Chrome 85 AppCache افتراضياً، مع تمديد مؤقت عبر تجربة مصدر للمواقع التي تحتاج وقتاً للانتقال. قدمت الإرشادات Service Workers طريقاً آخر لتجربة العمل بلا اتصال. وكانت هناك قاعدة قاطعة: عندما يسيطر Service Worker على صفحة في Chrome، يتوقف AppCache عن العمل لتلك الصفحة. لا يمكن بناء نصف آلية جديدة والاعتماد على القديمة لملء الفجوات.

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

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