Dlaczego pominęliśmy aplikację desktopową

Gdy pliki nie mogą opuścić prywatnej sieci, kolejnym pytaniem bywa instalator dla Windows albo macOS. Świadomie odrzuciliśmy taki model produktu. Graficzna aplikacja desktopowa byłaby drugą bazą kodu interfejsu. Rozjazd funkcji między „aplikacją” a /api/v1/ jest niemal nieunikniony, gdy te drzewa zaczną się różnić.

Ograniczeniem jest granica, nie oprawa

Warunek „bajty zostają tutaj” spełnia uruchomiony przez ciebie pdfx-server, a nie konkretnie WinForms czy Electron. Compose z pdfx (lokalnym albo --cloud przeciwko twojemu adresowi bazowemu) utrzymuje jeden katalog operacji za przeglądarką, REST, MCP i CLI.

Jak postawić ten stos, opisuje strona Self-host: task docker:build / task docker:up dla Compose (API na :8080, portal na :3000) albo natywny task pdfx:dev obok portalu do pracy lokalnej. Ustaw SECURITY_CUSTOMGLOBALAPIKEY, jeśli chcesz stałą bramkę. Ten wpis dotyczy wyłącznie tego, dlaczego ten stos nie jest opakowany w produkt desktopowy.

Lokalny pdfx bez --cloud uruchamia pdf-core na maszynie, na której leżą pliki. To już pokrywa zadania wsadowe offline, które nigdy nie potrzebowały interfejsu graficznego. Tryb chmurowy służy do sytuacji, gdy to samo CLI ma uderzać w twój self-hosted albo hostowany adres bazowy API z tym samym kontraktem multipart co curl.

Ile kosztowałby fork desktopowy

Konsumenckie pakiety optymalizują edycję na kanwie, porównywanie wizualne i instalatory ze sklepów. Utrzymanie takiego zestawu oznacza powielanie każdej nowej operacji (flag scalania, trybów OCR, domyślnych ustawień sanitizacji) w interfejsie graficznym, który nie jest kontraktem OpenAPI wywoływanym już przez agentów.

Wtyczki i kanały sklepowe mnożą koszty wsparcia, nie poprawiając działania MCP ani Idempotency-Key. Każdy cykl review w sklepie i każde okno uprawnień systemu to czas, który nie trafia do /v1/openapi.json. Gdy drzewo desktopowe wypuści opcję scalania, której nie ma API (albo odwrotnie), automatyzacje i dema rozjeżdżają się po cichu.

OCR to konkretny przykład, dlaczego duplikacja szkodzi. Obecna ścieżka serwera zwraca Markdown (text/markdown) w trybach Auto i Force (ocrType=force-ocr dla Force). Interfejs desktopowy, który nadal obiecywałby „przeszukiwalny PDF z ukrytą warstwą”, kłamałby o innym potoku. Jedna definicja operacji pozwala uniknąć tego rozłamu.

Jeden katalog, cztery klienty, zero drugiego interfejsu

Produkt ma już cztery sposoby dotarcia do tych samych operacji: formularz portalu, curl pod /api/v1/…, MCP pod /mcp oraz pdfx lokalnie albo w chmurze. Scal PDF jest konkretnym przykładem: łączy pliki w kolejności przesyłania, bez rasteryzowania stron do obrazów, niezależnie od tego, czy kliknąłeś „Przetwórz”, czy wysłałeś części fileInput.

Wydanie desktopowe byłoby piątym sposobem z osobnym cyklem wydawniczym. Tryb awarii, który nas interesuje, to nie „brak ikony w zasobniku systemowym”, lecz „strona demonstracyjna nadal działa, a skrypt zależny od tej samej operacji po cichu się psuje”.

Czego nie twierdzimy

Rezygnacja z wersji desktopowej nie tworzy w przeglądarce edycji interaktywnej klasy Acrobat. Produktem pozostają narzędzia formularzowe i zadania HTTP. Edytory online na kanwie, porównywanie wizualne i konsumenckie interfejsy podpisu celowo zostają poza zakresem. Jeśli potrzebujesz prywatnego wdrożenia, uruchom Compose i skieruj klientów na swój adres bazowy API. Jeśli potrzebujesz edytora pikseli, użyj pakietu stworzonego do tego; nie czekaj na plik .exe od PDF123.

Hostowany PDF123 pozostaje szybką anonimową ścieżką. Self-host to ten sam zestaw narzędzi za twoim firewallem. Żadna z tych ścieżek nie jest trzecią, rozbieżną edycją desktopową. Porównanie z konwerterami działającymi tylko w przeglądarce znajdziesz w Po co samodzielnie hostować zestaw narzędzi PDF. Co zyskujesz i czym zarządzasz opisuje Co naprawdę daje self-hosting. Jak cztery nie-desktopowe klienty pozostają zgodne wyjaśnia Ta sama operacja, cztery klienty.