الخلاصة

  • احتوى عنصر Gopher على النوع والاسم المعروض وselector معتم وhost وport. اختار القارئ الاسم، واستخدم العميل الحقول الأخرى لبدء اتصال جديد.
  • كان التسلسل الظاهر رسمًا بيانيًا من الإحالات. يستطيع ناشر القائمة اقتراح طريق، لكنه لا يملك الخادم المقصود ولا يثبت أن جوابه أصيل أو ثابت أو آمن.

قد تقود العبارة الودودة إلى مشغّل آخر

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

يعرّف RFC 1436 سطر الدليل بخمسة عناصر: type ثم الاسم المخصص للعرض، ثم Tab وselector، ثم Tab وhost، ثم Tab وport، وينتهي بـCRLF. يرى المستخدم الاسم غالبًا. أما العميل فيحصل على وصف قابل للتنفيذ للطلب التالي.

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

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

بقي معنى selector عند الخادم

بدت selectors في أمثلة كثيرة مثل مسارات ملفات. ومع ذلك طلب RFC 1436 ألا تعني شيئًا للعميل وألا يعدّلها.

حمت هذه القاعدة استقلال التنفيذ. يستطيع خادم أن يعامل النص pathname، ويستطيع آخر أن يرسله إلى script أو application أو query تولّد المستند. لم يفرض البروتوكول على الناشرين كشف أنظمة الملفات أو اعتماد معرّف عالمي واحد.

لكن الغموض لم يكن ضمانة. قد تعني البايتات نفسها شيئين مختلفين على hostين، وقد يغيّر الخادم تفسيرها بعد migration. لم يكن selector hash للمحتوى ولا credential ولا اسمًا دائمًا؛ كان مدخلًا إلى القواعد المحلية للخدمة المحددة.

لذلك ينبغي للسجل التشغيلي أن يحفظ البايتات الدقيقة. إن «إصلاح» slash أو تخمين encoding خاص أو حذف حرف غريب قد يطلب كائنًا آخر بصمت. جزء من ذكاء العميل هو معرفة الطبقة التي لا يملك فيها حق التفسير.

لم تكن الجذور مالكة لكل الفروع

اختار Gopher استعارة filesystem لأنها مألوفة، لا لأن topology الشبكة شجرة حقيقية. سمح RFC للقوائم بأن تشير إلى secondary servers، وإلى خدمات في أي مكان على الإنترنت، وحتى إلى عقد سابقة. كانت النتيجة arbitrary graph.

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

في كل انتقال بقيت الأدوار منفصلة. مصدر القائمة يكتب label وdescriptor. مشغّل الخادم البعيد يفسر selector. يمكن لمشغّل DNS نقل alias إلى عنوان جديد. وتحدد العملية الموجودة على port من يجيب فعلًا. ويقرر client هل يفهم type، بينما يختار reader من العناصر المعروضة فقط.

لذلك لم يثبت السطر إلا أن مصدرًا عرض هذا الطريق في وقت معين. قد يكون host خاطئًا أو selector قديمًا أو الاسم مضللًا. وقد يتغير DNS من دون تعديل القائمة. استمر الرسم البياني بتعاون جهات مستقلة، لا لأن سجلًا مركزيًا امتلك العلاقات كلها.

صنع العميل وهم الجلسة المتصلة

كانت المعاملة الأساسية قصيرة: فتح TCP وإرسال سطر selector يمكن أن يكون فارغًا. يرد الخادم، لكنه لا يحتفظ بحالة العميل بين المعاملات. كان CRLF وحده قادرًا على طلب top-level menu.

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

وهكذا لا يعني close دائمًا فشلًا؛ فقد يكون الحد الطبيعي لملف binary. والعكس صحيح: وجود نقطة النهاية الصحيحة يثبت framing فقط، لا صحة المعنى. قد تصل قائمة كاملة وكل مساراتها ميتة، أو يصل نص كامل لكنه ليس الوثيقة المقصودة.

كانت استمرارية التصفح ذاكرة محلية. اقترح RFC أن يحتفظ العميل بـstack للأماكن التي زارها أو cache للقوائم. لم تحتج الخوادم المتعاقبة إلى سجل session مشترك. تجمعت الرحلة من exchanges مستقلة ومن ذاكرة الجهاز القريب.

اختار type طريقة الحديث لا حقيقة الجواب

حدّد الحرف الأول ما يفعله العميل. كان 0 للنص و1 للقائمة و7 للبحث. وأشارت قيم أخرى إلى binary أو خدمات مثل CSO وTelnet وTN3270. يستطيع العميل تجاهل type غير أساسي لا يفهمه أو عرضه كمجهول.

لم يكن الحرف شهادة format أو authentication أو أمان. كان إشارة dispatch. فإذا صنّف ناشر القائمة الوجهة خطأ، قد يستخدم العميل transaction غير مناسبة مع endpoint متاح تمامًا.

في type 7 يرسل client الـselector ثم Tab ثم search string. ويعيد الخادم virtual menu. يمكن لمجموعة من indexes وgateways أن تغطي مجموعات مختلفة من دون تغيير نموذج العميل.

وظل كل search result إحالة. يقرر search server أن العنصر مطابق ويقدم إحداثياته، لكن host المقصود يسيطر على retrieval. لا يثبت الظهور في النتائج استمرار الوصول ولا صحة المطابقة ولا ثبات الوثيقة.

حفظت URI وصف الطلب لا هوية المحتوى

حوّل RFC 1738 الإحداثيات إلى URL: host وport اختياري وgophertype من حرف واحد وselector. إذا غاب port كان الافتراضي 70، وإذا خلا path أمكن أن يعني top-level menu من type 1، وفصل %09 بين selector والبحث.

حافظ RFC 4266 لاحقًا على scheme في Standards Track. صار الطريق قابلًا للحفظ والمشاركة خارج القائمة التي نشرته.

لكن URI لم يجمّد الكائن. ظل الخادم يفسر selector، وقد يغير DNS عنوان host، وقد تحل عملية جديدة محل القديمة على port. أصبح شكل الطلب قابلًا للتكرار، لا نتيجته ولا هوية المحتوى.

ولم يضف الترميز حماية. قال RFC 1436 صراحة إنه لا يناقش security. وحذّر RFC 4266 لاحقًا من غياب privacy ومن إرسال passwords في cleartext. الطريق الصحيح نحويًا لم يصبح طريقًا موثّقًا أو مشفرًا.

حملت خمسة حقول خيارًا مؤسسيًا كبيرًا

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

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

تتجاوز الفكرة بروتوكول Gopher. يمكن للدليل أن ينسّق الطرق ويجعل المواقع قابلة للعثور، لكنه لا يصبح مالكًا لكل نظام يذكره. من يحتفظ بدفتر العناوين لا يملك البيوت المسجلة فيه.

المصادر