الخلاصة

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

يبدأ فحص سلسلة الحيازة بوثيقة حالية تستجيب، ورابط prev-archive يعمل، وقاعدة محلية مليئة بالمدخلات. من السهل أن تتحول هذه الوقائع إلى عبارة واحدة: «الأرشيف كامل».

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

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

الأرشيف يقدم مساراً أقوى. تشير prev-archive إلى الوثيقة الأقدم مباشرة، ويمكن أن تشير next-archive نحو الأحدث، وتعيد current إلى وثيقة الاشتراك. وينبغي ألا يتغير محتوى وثيقة الأرشيف ولا عنوانها مع الوقت، حتى يستطيع العميل الاعتماد على ما عالجه سابقاً.

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

ثم تأتي عملية الاجتياز. يتبع العميل رابط prev-archive الذي لم يعالجه، ويضيف المدخلات، ويكرر ذلك حتى يصل إلى رابط عالجه سابقاً، أو إلى نهاية لا تحتوي رابطاً أقدم، أو إلى خطأ. ولا يلزم الناشر بإتاحة كل وثيقة؛ فقد يرفضها بـ403 أو 410، أو يعجز عن تقديمها بـ404. كما لا يلزم العميل دائماً بتخزين الخلاصة كلها أو إعادة بنائها، لكن عليه إبلاغ المستخدم عندما تكون النتيجة غير مكتملة.

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

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

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

يحتاج إيصال إعادة البناء إلى تسجيل:

  1. هوية وثيقة الاشتراك ووقت جلبها ووسم التحقق؛
  2. النوع المعلن ورسم الروابط المرصود فعلاً؛
  3. كل IRI وتحويل واستجابة وسياق مصادقة وبصمة محتوى؛
  4. ترتيب الاجتياز وإعادة المحاولة وحد الموارد وسبب التوقف؛
  5. سياسة التكرار وتعادل الأزمنة والحذف؛
  6. مراجعة الحالة المحفوظة وتاريخ القطع وحالة الاكتمال؛
  7. التحذير الذي ظهر فعلاً للمستخدم؛
  8. قراءة مستقلة لما عرضته واجهة القارئ.

هذا اقتراح حوكمة لا مطلب مخفياً في RFC 5005. وهو يطبق فصل طبقات الواقع لدى Heng Lu: تصريح الناشر، وانتقال الشبكة، والحالة المتحققة، ومشاهدة الإنسان لا تصبح حقيقة واحدة إلا بدليل يصل بينها.

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

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

المصادر