الخلاصة

  • في RFC 1013، يبدأ اتصال X11 ببايت قيمته 102 بالنظام الثماني، أي الحرف B الكبير، للدلالة على إرسال البايت الأعلى أهمية أولاً؛ أو 154 بالنظام الثماني، أي الحرف l الصغير، للدلالة على البدء بالأقل أهمية. تتبع حقول البروتوكول المعتادة ذات 16 و32 بت اختيار العميل.
  • تتبع بيانات الصور النقطية وصور البكسل الصيغ التي يعلنها الخادم، بما فيها ترتيب بايتات الصورة. يبدّل الخادم بايتات الحقول المعتادة عند الحاجة؛ ويهيئ العميل بايتات الصورة وفق ما يطلبه الخادم.

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

نشرت RFC 1013 في يونيو 1987 تحديثاً أولياً للنسخة الحادية عشرة من بروتوكول X. يمكن للعملاء البعيدين استعمال أي تيار بايتات موثوق؛ وعند استخدام TCP يستقبل خادم الشاشة ذات الرقم N على المنفذ 6000 زائد N. أول بايت يرسله العميل يحدد ترتيب حقول 16 و32 بت. كتبت الوثيقة القيمتين بالنظام الثماني: 102 يقابل B الكبير في ASCII مع البايت الأعلى أولاً، و154 يقابل l الصغير مع البايت الأدنى أولاً. هذا الحرف الصغير يوزع واجب الترجمة قبل أي نافذة.

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

ثم تحضر الصورة، وتستلم إدارة أخرى الملف. صور bitmap وpixmap تنتقل في صيغ يحددها الخادم. ترسل استجابة الإعداد ترتيب بايتات الصورة، ووحدات السطر في bitmap وحشوه، وصيغ pixmap المتاحة. في XYFormat يطبق الترتيب على كل وحدة من السطر؛ وفي ZFormat على قيمة كل بكسل. إذا خالف ترتيب الصور الأصلي لدى العميل ما أعلنه الخادم، يبدل العميل البايتات بنفسه. الشاشة التي ستعرض الصورة تختار كيف تُعبأ بياناتها.

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

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

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