وصل الجدول بالبريد، ومعه سؤال «ماذا لو؟»

الخلاصة

• سجلت RFC 910 اجتماعاً عن البريد متعدد الوسائط في يوليو 1984. قدمت BBN نسخة أولى مكتملة من Diamond على محطة Jericho، تتبادل وثائق تجمع النص والرسوم والصور والصوت وجداول البيانات.
• كان كائن الجدول يحمل النموذج إلى جانب البيانات. يستطيع برنامج قارئ متقدم تبديل الأرقام واختبار نتيجة أخرى؛ ويعرض برنامج أبسط قيم الخلايا دون تشغيل الصيغ. ناقش المجتمعون أيضاً طريقة نقل قصد الكاتب في ترتيب الوثيقة بين شاشة وطابعة مختلفتين.

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

دوّن Harry Forsdick في RFC 910 ما جرى في اجتماع BBN يومي 23 و24 يوليو. عرضت BBN وISI وSRI وLinkabit أنظمة وتجارب في مراحل مختلفة. قالت BBN إن التنفيذ الأولي لـDiamond اكتمل على محطة Jericho، وصار يتبادل وثائق مركبة من النصوص والرسوم والصور والصوت وجداول البيانات والرسوم البيانية. كان ISI يطور واجهة على Xerox 1108، ويستخدم وحدة معالجة رسائل على TOPS-20 مع تحويل إلى بريد SMTP المعتاد. وقدمت SRI نظاماً على Sun فيه إدارة للرسائل وتحرير لبنية الوثائق ووحدة نقل، تدعم عندها النص والصوت والرسوم. امتلأت الغرفة بأجزاء منظومة تريد أن تتفاهم.

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

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

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

سبقهم Jon Postel بوثيقتين أساسيتين: وصفت RFC 759 بروتوكول رسائل الإنترنت ووحدات معالجته، وقدمت RFC 767 بنية لنقل الوثائق متعددة الوسائط. في اجتماع 1984 تحولت الأفكار إلى أسئلة تنفيذية: أي تمثيل للرسوم يستخدم الآن، وكيف تتبادل محطات العمل المختلفة الوثائق، وكيف يُحوَّل البريد الغني إلى رسائل SMTP النصية؟ اختار المجتمعون تمثيل Diamond للرسوم حلاً مؤقتاً اسمه MMGraphics1، مع متابعة تطوير معايير أوسع.

وضعت المحاضر مواعيد واضحة. كان الانتقال إلى البنية الجديدة مقرراً أن يكتمل بحلول 1 أكتوبر 1984، والتجربة التالية مخططة ليناير 1985 وتشمل النص والرسوم والصور والصوت. توقعت BBN ما بين 100 و200 مستخدم في بيئة ADDCOMPE التجريبية خلال العام التالي؛ ذلك عدد متوقع. جدول Diamond كان ضمن العمل الذي عُرض في الاجتماع، أما التبادل المعتاد بين البرامج المختلفة فاحتاج إلى مزيد من التنفيذ والتنسيق.

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