حُفظت المجموعة، لا سبب اختيارها

الخلاصة

• ينشئ SEARCH RETURN (SAVE) في RFC 5182 قيمة واحدة قابلة للاستبدال، ويشير $ إلى قيمتها الحالية. لا يمنحها اسماً دائماً ولا يحفظ الاستعلام بوصفه كياناً مستقلاً.
• عند رفض الحفظ بسبب الموارد يعيد الخادم NO مع NOTSAVED ويفرغ القيمة. لا يبقى الناتج القديم كبديل، لذلك يجب إيقاف سلسلة التنفيذ وإعادة بنائها صراحة.

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

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

اختصار للشبكة لا مستودع للاستعلامات

من دون SEARCHRES يعيد الخادم قائمة نتائج SEARCH، ثم يحللها العميل ويعيد إرسالها كـ message-set إلى FETCH أو STORE أو COPY أو SEARCH أخرى أو UID EXPUNGE. مع خيار SAVE يحتفظ الخادم بالمجموعة داخلياً، ويضع العميل $ مكان القائمة.

يعلن الخادم capability باسم SEARCHRES، ويلزمه دعم ESEARCH أيضاً. وإذا لم يطلب العميل خيار نتيجة آخر، يمنع SAVE استجابة SEARCH التي كانت ستعرض القائمة. قد يستخدم العميل المجموعة من دون أن يتلقى معرفاتها أصلاً.

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

إذا احتاج المنتج إلى «بحث محفوظ»، فعليه إنشاء كيان محلي يحمل معرفاً ثابتاً، ومعايير البحث والنطاق والمالك والوقت والعدد المتوقع. لا يتحول $ إلى ذلك الكيان بمجرد تغيير الاسم في الواجهة.

الموارد جزء من نتيجة SAVE

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

إعلان capability لا يحجز ذاكرة لكل عميل، ولا يثبت أن كل محاولة SAVE ستنجح. يجب أن يفصل الرصد بين نجاح البحث ونجاح تثبيت النتيجة. كما يجب ألا يتابع automation إلى STORE أو COPY بعد NO وكأن المجموعة السابقة بقيت سليمة.

يفرق المعيار بين حالات أخرى. SEARCH المنتهي بـBAD لا يغير المتغير. SEARCH بلا SAVE لا يغيره، سواء نجح أو عاد NO. أما SEARCH مع SAVE إذا عاد NO فيفرغه. هذه الفروق هي آلة الحالة، وليست تفاصيل صياغة يمكن توحيدها في «فشلت المحاولة».

إعادة المحاولة الصحيحة تعيد إنشاء البحث والسياق وتمنح العملية هوية جديدة. إعادة الأمر المستهلك وحده لا تعيد النتيجة التي لم تُحفظ.

الفراغ قيمة صحيحة

يمكن للبحث ألا يجد رسائل. ويمكن لـSELECT أو EXAMINE ناجح أن يصفر المتغير. UIDVALIDITY جديد يفعل الشيء نفسه. وقد يزيل EXPUNGE العضو الأخير. وفي كل هذه الحالات يبقى $ مجموعة صحيحة لا تطابق شيئاً.

لهذا قد ينتهي FETCH $ بـOK من دون أي استجابة FETCH. ويعرض RFC مثال COPY ينتهي بنجاح ولا ينسخ شيئاً. صحة الأمر لا تثبت أن هدف الاحتفاظ أو الترحيل أو الحماية أصاب رسالة واحدة.

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

مؤشر يعتمد على نسبة OK يقيس قبول الأوامر فقط. وقد يمنح اللون الأخضر لعملية لم تنفذ أي عمل تجاري.

الاختيار وUIDVALIDITY يحددان العالم

بعد SELECT أو EXAMINE ناجح يعاد المتغير إلى الفراغ، لأن أرقام التسلسل تكتسب معناها داخل صندوق محدد. أما UID فلا يكون ثابتاً إلا مع اسم الصندوق وUIDVALIDITY. عند تغير الجيل تسقط سلطة المراجع القديمة.

يغير EXPUNGE المجموعة من دون بحث جديد. يخرج العضو المحذوف، وإذا خزن الخادم أرقام تسلسل فعليه تعديل الأرقام الباقية. المجموعة عند الإنشاء ليست بالضرورة المجموعة عند التنفيذ.

كما يحدد الأمر المستهلك طريقة تفسير $. يمكن لنتيجة SEARCH عادية أن تدخل UID FETCH فتفسر كـUID، ويمكن لنتيجة UID SEARCH أن تدخل FETCH فتفسر كأرقام تسلسل. اسم المنتج وحده لا يثبت فضاء الهوية.

لذلك يحتاج السجل إلى الاتصال، والصندوق المختار، وUIDVALIDITY، وأمر SAVE ومعاييره وخياراته، وترتيب الاستلام، وأحداث EXPUNGE، وشكل كل أمر مستهلك.

الترتيب يحكم الأوامر المتوازية

عندما يتبع SAVE أمر يستخدم $ تنشأ تبعية مباشرة، ويلزم الخادم ترتيب الاستلام. يستطيع تحسين التنفيذ داخلياً ما دام المعنى الظاهر محفوظاً. ويمكن لنتيجة واحدة أن تغذي COPY ثم STORE بترتيب واضح.

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

ينبغي أن يشير كل مستهلك محلياً إلى SAVE الفعال عند موقعه في سلسلة الأوامر. وعند الحاجة إلى سياقات متعددة أو تحديثات مستمرة، يوضح RFC 5267 أن CONTEXT عقد مختلف يمكن تمييزه بالـtag وتحديثه وإلغاؤه. لا يجوز تحميل خانة «آخر نتيجة» وظيفة مكتبة سياقات.

خيارات النتيجة تغير محتوى الخانة

لا يعني SAVE دائماً حفظ كل المطابقات. مع ESEARCH يحفظ SAVE MIN العنصر الأدنى فقط، وSAVE MAX الأعلى فقط، ويجمع الاثنان طرفاً أو طرفين. وجود ALL أو COUNT يفرض حفظ المجموعة الكاملة.

يضيف RFC 9394 أن SAVE مع PARTIAL، من دون ALL، يحفظ نافذة جزئية مع MIN أو MAX المناسب. ويطلب RFC 9738 حفظ الجزء المقطوع عند MESSAGELIMIT؛ وقد عالج BTW حد الاكتمال هذا في مقال مستقل. الحد هنا مختلف: حتى البحث الكامل تتحدد قيمته بخيارات العودة، لا بعنوان المهمة البشرية.

لذلك يجب أن يسجل القرار هل فوض كل النتائج أم طرفاً أم صفحة. كلمة «المجموعة المحفوظة» وحدها لا تجيب.

إثبات السلطة خارج الرمز

يسجل IANA capability SEARCHRES، ويدمج RFC 9051 آلة حالتها في IMAP4rev2. يثبت ذلك لغة مشتركة، لا نشر منتج معين ولا توافر الموارد ولا صحة automation ولا اكتمال نتيجة عامة.

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

سؤال الإغلاق ليس «هل قال الخادم OK؟» بل: هل يمكن تفسير سبب دخول كل رسالة في القرار، وسبب غياب كل رسالة كانت ضمن المقصود؟ إذا لم يبق إلا الرمز، فقد اختفت الحقيقة مع الجلسة.

المصادر

1. RFC 5182 — HTML
2. RFC 5182 — نص عادي
3. صفحة معلومات RFC Editor
4. صفحة الوثيقة في IETF Datatracker
5. سجل IETF Datatracker
6. مراجع IETF Datatracker
7. تصحيحات RFC 5182
8. RFC 9051 — IMAP4rev2
9. صفحة معلومات RFC 9051
10. RFC 4731 — ESEARCH
11. RFC 4466 — ABNF المجمعة لـIMAP
12. RFC 4315 — UIDPLUS
13. RFC 3501 — IMAP4rev1
14. RFC 5267 — IMAP CONTEXT
15. RFC 9738 — MESSAGELIMIT
16. RFC 9394 — PARTIAL
17. سجل قدرات IMAP لدى IANA
18. Heng Lu — طبقات الواقع
19. Heng Lu — الحد الأدنى للمواصفة الأولية والتبني الطوعي
20. Heng Lu — أولوية الكود العامل