Summary

  • أتاح Prospero للمستخدمين والمشرفين إنشاء عروض دليل افتراضية فوق ملفات وفهارس بعيدة، من دون نقل البيانات أو تفسيرها.
  • وثّق تقرير 1994 صلاته بـ Archie وGopher وخططاً لدمج WAIS والويب؛ ثم ذكر RFC صدر في 2005 أن البروتوكول لم يُطبّق على نطاق واسع.

دليل يعكس طريقة نظر المستخدم

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

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

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

العثور والتنظيم والاسترجاع أعمال مختلفة

لم يكن Prospero اسماً آخر لـ Archie. فقد أنشأ Archie فهرساً لأسماء ملفات FTP ومواقعها، في حين استطاع Prospero إظهار قاعدة Archie ضمن دليل أوسع. كما لم يكن مجرد نسخة من Gopher؛ إذ وصف تقرير 1994 بوابة تستطيع التعامل مع خوادم Gopher كقواعد بيانات وضمها إلى مصادر أخرى.

حدّد المشروع حدود وظيفته أيضاً. لم يفسر Prospero البيانات التي ينظمها. قدّم وسائل للاسترجاع، لكن التطبيق هو الذي يقرر طريقة العرض والاستخدام. ولم يكن له بروتوكول مستقل لنقل الملفات: أمكن الوصول عبر FTP أو NFS أو AFS أو Gopher، واستخدام Telnet للخدمات التي تتطلب تسجيل الدخول. ساعد الدليل على تحديد الموقع وطريقة محتملة للوصول، لكنه لم يضمن حداثة الملف أو سماح الخادم أو ملاءمة المحتوى.

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

خريطة تحكمها صلاحيات

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

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

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

طموح موثق وانتشار محدود

قدّر تقرير عن أدوات استرجاع المعلومات الشبكية صدر في 1994 عدد خوادم Prospero بنحو خمسين. وكانت بيانات الخوادم والعملاء قد حُدّثت في نوفمبر 1993. هذا تقدير أبلغ عنه المشروع في وقت محدد، وليس قياساً لعدد المستخدمين أو الأدلة التي ظلت نشطة. ووصف التقرير التكامل مع Archie وGopher، بينما وضع فهارس WAIS ووثائق الويب ضمن الخطط المقبلة.

في 2005 أبقى RFC 4157 مخطط URI الخاص بـ Prospero، لكنه صنّف الوثيقة تاريخية. وذكر صراحة أن البروتوكول لم يُطبّق على نطاق واسع وأنه لم يبقَ تقريباً أي خادم مستخدم. لا يمحو ذلك قيمة التجربة المعمارية، لكنه يحد من الاستنتاج: جعل Prospero تنظيم الموارد الموزعة ممكناً، من دون أن يصبح طبقة دليل واسعة الانتشار.

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

تكمن المسألة التاريخية في الاختيار الذي جسّده النظام: فهرس عالمي واحد أم خرائط محلية متعددة فوق موارد تبقى لدى ناشريها؟ جرّب Prospero الخيار الثاني. ويبين نطاقه المحدود أن توزيع التنظيم يحفظ الاستقلال المحلي، لكنه لا يلغي كلفة التنسيق والرعاية المستمرة.

المصادر