لماذا تخطّينا تطبيق سطح المكتب

حين يجب ألا تغادر الملفات شبكة خاصة، يكون الطلب التالي غالباً مثبّتاً لنظام Windows أو macOS. وقد رفضنا ذلك الشكل عن قصد: فالواجهة الرسومية المكتبية ستكون قاعدة كود ثانية للواجهة، وانحراف الميزات بين «التطبيق» و/api/v1/ شبه حتمي بمجرد أن تتباعد الشجرتان.

القيد هو الحدّ لا المظهر

عبارة «تبقى البايتات هنا» يحققها خادم pdfx-server تشغّله أنت، لا WinForms ولا Electron تحديداً. فـ Compose مع pdfx محلياً أو بـ --cloud مقابل عنوانك الأساسي، يبقي كتالوج عمليات واحداً خلف المتصفح وREST وMCP وأداة سطر الأوامر.

وطريقة إقامة ذلك المكدس موثّقة على الاستضافة الذاتية: الأمران task docker:build وtask docker:up لـ Compose حيث تعمل API على المنفذ :8080 والبوابة على :3000 أو task pdfx:dev أصلياً بجوار البوابة للعمل المحلي. واضبط SECURITY_CUSTOMGLOBALAPIKEY حين تريد بوابة ثابتة. وهذا المقال عن سبب عدم تغليف ذلك المكدس كمنتج مكتبي فحسب.

ويشغّل pdfx المحلي من دون --cloud نواة pdf-core على الجهاز الذي يحمل الملفات، وهذا يغطي أصلاً مهام الدفعات دون اتصال التي لم تحتج واجهة رسومية قط. أما وضع السحابة فلحين يجب أن تصل الأداة نفسها إلى قاعدة API المستضافة أو الذاتية بعقد الأجزاء المتعددة نفسه الذي يستعمله curl.

ما تكلفه نسخة مكتبية

تُحسّن الحزم الاستهلاكية تحرير لوحة الرسم، والمقارنة البصرية، ومثبّتات المتاجر. وصيانة ذلك السطح تعني تكرار كل عملية جديدة، من أعلام الدمج وأوضاع OCR وافتراضات التنقية، في واجهة رسومية ليست عقد OpenAPI الذي يستدعيه الوكلاء بالفعل.

وتضاعف الإضافات وقنوات المتاجر كلفة الدعم من دون تحسين سلوك MCP أو Idempotency-Key. وكل دورة مراجعة في متجر وكل مطالبة إذن نظام هي وقت لا يستقر في /v1/openapi.json. وبمجرد أن تُصدر الشجرة المكتبية خيار دمج لا تملكه الواجهة، أو العكس، تختلف الأتمتة والعروض التوضيحية صامتةً.

وOCR مثال ملموس على أن التكرار يضرّ. فمسار الخادم الحالي يعيد Markdown (text/markdown) بوضعي Auto وForce، حيث يمثّل ocrType=force-ocr وضع Force. وواجهة مكتبية ما زالت تَعِد بـ «ملف PDF قابل للبحث بطبقة مخفية» ستكون كاذبة عن مسار مختلف. والاحتفاظ بتعريف عملية واحد يمنع ذلك الانقسام.

كتالوج واحد، أربعة عملاء، وبلا واجهة ثانية

للمنتج أصلاً أربعة مقابض على العمليات نفسها: نموذج البوابة، وcurl إلى /api/v1/… وMCP عند /mcp وpdfx محلياً أو سحابياً. والدمج المثال الملموس: اجمع ملفات PDF بترتيب الرفع من دون تحويل الصفحات إلى صور، سواء نقرت زر المعالجة أو أرسلت أجزاء fileInput.

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

ما لا نزعمه

تخطّي تطبيق سطح المكتب لا يخترع تحريراً تفاعلياً بمستوى Acrobat في المتصفح. فالأدوات القائمة على النماذج ومهام HTTP تبقى المنتج. وتبقى لوحات التحرير على الإنترنت والمقارنة البصرية وواجهات التوقيع الاستهلاكية خارج النطاق عن قصد. وإن احتجت نشراً خاصاً، فشغّل Compose ووجّه العملاء إلى عنوان API خاصتك. وإن احتجت محرّر بكسلات، فاستخدم حزمة مبنية لذلك؛ ولا تنتظر ملف .exe من PDF123.

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