diff --git a/AI.md b/AI.md index 26ec6b9..b7b5ff2 100644 --- a/AI.md +++ b/AI.md @@ -47,7 +47,7 @@ unfinished work out of `TODO.md` merely because its architecture is documented. Latest patch marker expected in an up-to-date bundle: -- `0474 docs: name nwConsole and clarify web restart boundaries` +- `0475 docs: record nwadmin platform transport choices` When a later chat receives a new `mars-nwe-master` bundle, compare `git log -1` with this marker. If the uploaded bundle already contains this commit subject, @@ -67,24 +67,21 @@ The active line is expected to include: Last generated patch: -- `0474 docs: name nwConsole and clarify web restart boundaries` +- `0475 docs: record nwadmin platform transport choices` Purpose of that patch: -- Define user-facing names: `nwConsole` for the browser/web administration - surface and `nwAdmin` for the remote/desktop administrator client family. - The small web listener process may remain `nwwebui` internally. -- Clarify lifecycle boundaries: a host-level systemd/init restart may restart - the whole MARS-NWE service family including `nwwebui`, but restarts requested - from nwConsole must keep the web listener alive unless the operator explicitly - restarts the web frontend itself. -- Require embedded nwConsole static/status pages in `nwwebui` for backend - restart and reconnect states such as `Restarting nwadmin`, `Restarting - ncpserv`, `Restarting nwconn`, `Restarting nwbind`, backend unavailable and - reconnect pending. -- Keep the split from the previous plan: `nwwebui` owns HTTP/HTTPS/TLS/session - and IPC frontend work, while `nwadmin` owns web/config plugins and backend - management dispatch. +- Clarify the remote `nwAdmin` transport backend choices while keeping the + portable admin API as the only API visible to GUI, console and web/plugin + callers. +- Keep Linux on the ncpfs-first investigation path for NetWare 3.x admin NCP + operations. +- Treat Windows as Novell Client first where practical, because that client stack + is normally required there anyway; do not revive the old Pascal VLM/NWTP layer + as the new Windows runtime. +- Treat the historical Novell NetWare Client for Macintosh as a Classic/PPC + compatibility/reference path only; modern macOS needs either an ncpfs + client-library port or a small project-owned NCP transport adapter. Directory/NDS work order before any FLAIM storage conversion: diff --git a/REDESIGN.md b/REDESIGN.md index 1c60366..2cdcac0 100644 --- a/REDESIGN.md +++ b/REDESIGN.md @@ -2571,8 +2571,12 @@ Terminal UI, toolbox and curses replacement plan: storage work are ready. - A future GUI may use Lazarus LCL/FreePascal or another cross-platform toolkit, but the GUI must stay above the portable admin client API. On Linux the first - backend should investigate ncpfs; macOS may require an ncpfs port or a small - project-owned NCP client transport; Windows needs a later backend audit. + backend should investigate ncpfs. On Windows, the practical first backend + should wrap the installed Novell Client because that client stack is normally + required there anyway; do not revive the old Pascal VLM/NWTP runtime layer for + new code. For Classic/PPC macOS, the historical Novell NetWare Client for + Macintosh is only a compatibility/reference path; modern macOS needs either an + ncpfs client-library port or a small project-owned NCP transport. - Keep the first admin client simple. Rich Pascal GUI/web stacks such as custom-drawn Lazarus libraries or browser-oriented Pascal frameworks can be evaluated later, but they must not become required dependencies for the common diff --git a/TODO.md b/TODO.md index df5628d..7616da7 100644 --- a/TODO.md +++ b/TODO.md @@ -113,7 +113,7 @@ may remain active. | `0x2222/22/51 Get Extended Volume Information` | partial / implemented compatibility | Keep active compatibility code; verify volume fields and ensure 3.x clients are not regressed. | | Other Directory Services 4.x high selectors | later / guarded | Document exact request/reply layout before enabling default runtime behaviour. | | Additional File Server Environment 4.x monitor/admin selectors | later / guarded | Implement only when a concrete admin tool or compatibility test requires it. | -| Remote `nwadmin` 3.x client roadmap | 3.x | open | Audit `mars-nweadmin` workflows and define a portable NCP-based admin client API. Linux should investigate ncpfs behind a transport adapter; macOS and Windows backends remain open until the 3.x NCP needs are known. Do not link the admin GUI directly to local server libraries. | +| Remote `nwadmin` 3.x client roadmap | 3.x | open | Audit `mars-nweadmin` workflows and define a portable NCP-based admin client API. Linux should investigate ncpfs behind a transport adapter. Windows should wrap the installed Novell Client first where practical, hidden behind the same adapter. Classic/PPC macOS may use the historical Novell NetWare Client only as a compatibility/reference path; modern macOS needs either an ncpfs port or a project-owned NCP transport. Do not link the admin GUI directly to local server libraries. | | Remote admin GUI frontend | later / guarded | open | A GUI may use Lazarus LCL/FreePascal or another cross-platform toolkit, but only after the portable admin client API has a console/CTest frontend. Keep first-pass dependencies small; Cross.Codebot/TMS WEB Core/uniGUI-style stacks are later evaluations, not required dependencies. Directory/ConsoleOne-like features come later after the directory stack is ready. | | Server-local nwConsole/nwadmin admin frontend | later / guarded | open | Replace the old SMArT role with a split design: `nwwebui` is the small HTTP/HTTPS/TLS/session/static frontend and SSL offloader exposed to users as nwConsole; `nwadmin` is the backend process that owns web/config plugins and calls the portable admin API. Keep bindery/server authentication first for 3.x, later directory/`libnwds` authentication first for 4.x, PAM fallback only, `libowfat` for socket/helper work where suitable, and MatrixSSL/`libnwssl` for TLS. A host-level systemd/init restart may restart the whole MARS-NWE service family including `nwwebui`, but nwConsole-requested backend restarts must keep `nwwebui` running unless the operator explicitly restarts the web frontend. `nwwebui` needs embedded nwConsole status pages for `Restarting nwadmin`, `Restarting ncpserv`, `Restarting nwconn`, `Restarting nwbind`, backend unavailable and reconnect states. Replace SMArT-style subprocess console-output coupling with an explicit local IPC socket between `nwwebui` and `nwadmin`. | | NDS/NCP Fragger and related 4.x infrastructure | later / guarded | Keep out of default runtime until transport/client scope is explicit. | diff --git a/doc/NWADMIN_CLIENT_PLAN.md b/doc/NWADMIN_CLIENT_PLAN.md index fcc6592..018e587 100644 --- a/doc/NWADMIN_CLIENT_PLAN.md +++ b/doc/NWADMIN_CLIENT_PLAN.md @@ -57,15 +57,22 @@ Initial direction: - Linux: prefer the existing ncpfs client library where it can provide the 3.x NCP operations needed by the admin client. -- macOS: investigate whether ncpfs can be ported or whether a small project-owned - NCP client transport is required. -- Windows: do not rely on the old Delphi/VLM/NWTP layer for new code. Choose a - backend only after auditing realistic options: native client API if available, - a ported ncpfs-like backend, or a project-owned NCP transport. +- Windows: expect the Novell Client to be the practical first backend. A + Windows administrator workstation normally needs that client stack anyway for + authentic NetWare access, so `nwAdmin` should wrap a Windows Novell Client + backend through the same transport adapter instead of reviving the old Pascal + VLM/NWTP layer. A project-owned NCP backend can remain a later fallback only + if the native client path is unavailable or too limited. +- Classic/PPC macOS: treat the historical Novell NetWare Client for Macintosh as + a compatibility reference for old systems where it is available, not as a + modern portable dependency. +- Modern macOS: plan for either an ncpfs client-library port or a small + project-owned NCP transport behind the adapter, because the old Macintosh + client does not solve current macOS targets. The GUI must call only the portable admin client API. Platform-specific NCP -attachment, login, request framing, timeouts, and reconnect behaviour belong -below that API. +attachment, login, request framing, timeouts, reconnect behaviour, and native +client integration belong below that API. ## GUI direction @@ -223,15 +230,20 @@ the IPC socket when the backend comes back, and show an embedded nwConsole 2. Define a portable admin client API over NCP for the 3.x path. 3. Implement a Linux backend using ncpfs where practical, with the backend hidden behind the transport adapter. -4. Add a console/CLI test frontend so CTest can exercise the client API without a +4. Add a Windows transport adapter that wraps the installed Novell Client where + practical, because that is the expected first Windows backend. +5. Audit the old Macintosh NetWare client as a Classic/PPC reference only, then + decide whether modern macOS needs an ncpfs port or a project-owned NCP + transport. +6. Add a console/CLI test frontend so CTest can exercise the client API without a GUI. -5. Add a simple server-local nwConsole (`nwwebui`) plus `nwadmin` pair only after the API is +7. Add a simple server-local nwConsole (`nwwebui`) plus `nwadmin` pair only after the API is stable enough: `nwwebui` handles HTTP/HTTPS/TLS/session/static frontend work, while `nwadmin` owns plugin dispatch and management operations. -6. Add a desktop GUI frontend only after the admin client API and transport +8. Add a desktop GUI frontend only after the admin client API and transport behaviour are stable and the toolkit choice does not force large dependencies into the common/server side. -7. Later, when LDAPv2/LDAPv3, schema import, `libnwds`, console `nwsetup`, and +9. Later, when LDAPv2/LDAPv3, schema import, `libnwds`, console `nwsetup`, and the FLAIM-backed directory stack are ready, extend the admin client toward directory administration in a ConsoleOne-like direction. @@ -243,8 +255,12 @@ the IPC socket when the backend comes back, and show an embedded nwConsole server. - Do not combine the 3.x admin-client transport work with the later Directory/NDS management work. -- Do not choose the final macOS or Windows transport backend before the 3.x NCP - API needs have been audited. +- Do not make modern macOS depend on the old Classic/PPC Novell Client. Use it + only as a compatibility/reference path; modern macOS needs either an ncpfs port + or a project-owned NCP transport adapter. +- Do not revive the old Pascal VLM/NWTP runtime layer for Windows. Prefer the + installed Novell Client backend first, hidden behind the portable transport + adapter. - Do not make Cross.Codebot, TMS WEB Core, uniGUI, or any other large GUI/web framework a required first-pass dependency. - Do not merge HTTP/HTTPS/session handling into `nwserv`; keep `nwwebui` or an