الملخص

  • تضيف النسخة 05 من مسودة JMAP Object Metadata، المؤرخة 28 أكتوبر، قيمة Binary ذات عضوين فقط: @type وbase64 صحيح مع حشو. يحفظ الخادم القيمة السليمة ويعيدها بالشكل نفسه، ويرفض البنية الفاسدة.
  • تُحسب القيمة بعمق صفر، لكن مسار الاستعلام أو التعديل لا يدخل أعضاءها، ولا يطابقها مرشح نصي. لم تتضمن النسخة 04 هذا القسم.

العثور على العلبة أسهل من العثور على ما فيها

تضع المسودة في مثالها بصمة من 32 بايت داخل مساحة أسماء يملكها مورّد. يمكن للاستعلام أن يثبت وجود الحقل. أما البحث عن تسلسل بايتات داخل البصمة فلن ينجح بمرشح نصي؛ فالقيمة الثنائية ليست نصاً قابلاً للفحص. وتفشل محاولة تعديل عضو base64 وحده. من يريد تغيير البصمة يستبدل القيمة كاملة.

جاء التغيير لأن سلسلة JSON تحمل نص Unicode، بينما قد تحتاج التطبيقات إلى بايتات لا تمثل نصاً. يحدد القسم الجديد غلافاً ذا عضوين لا ثالث لهما، وترميز base64 صحيحاً مع الحشو؛ الخطأ يؤدي إلى invalidProperties. ومسار التعديل الذي يحاول المرور عبر الغلاف ينتهي إلى invalidPatch. الخادم أمين حفظ، وليس صاحب تفسير للبصمة.

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

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

تُظهر صفحة IETF مسودة عمل لمجموعة JMAP. ينقص الحكم التشغيلي أثر خادم محدد يكتب القيمة، ويعيدها بايتاً ببايت، ويختبر البحث والتعديل والحصة. رسمت الوثيقة القفل بدقة؛ تشغيله يحتاج سجلاً.

المصادر: النسخة 05؛ النسخة 04؛ حالة IETF.