diff --git a/REDESIGN.md b/REDESIGN.md index 54fe749..c04df97 100644 --- a/REDESIGN.md +++ b/REDESIGN.md @@ -1094,13 +1094,19 @@ third_party/wolfssl fixed TLS dependency used by mars-nwe TLS code configured through CMake for the server's supported platforms and features +third_party/libflaim + planned fixed directory storage engine used through libdirectory + mars-nwe-maintained import/fork of the FLAIM source + converted to a real standalone-and-subdirectory CMake build + third_party/zlog optional advanced logging backend used only through nwlog mars-tinyldap/ forked/integrated tinyldap-derived component in the repository root - project-facing service name: nwdirectory - converted to the mars-nwe CMake build + upstream/standalone project identity remains tinyldap + mars-nwe service/binary name: nwdirectory + converted to a real standalone-and-subdirectory CMake build later wired to libdirectory/libflaim instead of tinyldap's original flat files ``` @@ -1162,29 +1168,89 @@ future backend changes centralized. zlog can provide administrator-controlled category/rule/format routing, but it must never receive raw decoded NCP or handoff payloads from bypass paths. +### libflaim storage engine rule + +`libflaim` should live under `third_party/libflaim`, not at the repository root. +It is a bundled storage engine dependency for the future directory store, not a +mars-nwe service component. The initial import may come from the SourceForge +FLAIM code base or from a distro-vetted source package such as the openSUSE +`libflaim-4.9.1046` source package, but the exact source must be recorded. + +The imported tree is expected to need a mars-nwe-maintained fork because the +original build system is too hard to integrate directly. Do not merely wrap the +old Makefiles from CMake. Replace the build integration with a real CMake build +that can work both ways: + +```text +standalone: + cmake -S third_party/libflaim -B build-flaim + +inside mars-nwe: + add_subdirectory(third_party/libflaim) + target_link_libraries(directory PRIVATE FLAIM::flaim) +``` + +The CMake conversion should separate the library from optional tools/tests, +expose a normal target such as `FLAIM::flaim`, and support static/shared choices +where useful. The original Makefiles may remain as reference material during the +import, but they should not be the long-term build path. + +FLAIM is C++ code. That is acceptable, but its C++ API must not leak into the +old mars-nwe C code. `nwbind`, future `nwnds`, `nwdirectory`, and `nwsetup` +should use a C ABI through `include/libdirectory.h` or an equivalent internal +`libdirectory` API. Only the `libdirectory` implementation should know that the +store underneath is libflaim. + +The final import must include `third_party/libflaim/README.mars-nwe.md` or an +equivalent note listing: + +- import source and version/revision; +- distro package and distro patches, if used; +- library source license, observed as LGPL-2.1 in the inspected source; +- separate helper/tool licenses such as BSD-3-Clause for files like `svn2cl.xsl`; +- local CMake and portability changes; +- how mars-nwe links it through `libdirectory`. + ### Forked tinyldap / nwdirectory rule -`tinyldap` is different from yyjson, wolfSSL, and zlog. It is not merely a small -library dependency. The planned integration requires a fork because the original -code needs mars-nwe-specific work: +`tinyldap` is different from yyjson, wolfSSL, zlog, and libflaim. It is not a +small library dependency and it is not merely a storage engine. It becomes the +LDAP service component used by mars-nwe, so it follows the existing root-level +component pattern used by `admin`, `dosutils`, `mail`, and `smart`. -- CMake build support; -- mars-nwe service naming (`nwdirectory`); +The repository name can be `mars-tinyldap/`, but the upstream/standalone project +identity should remain `tinyldap`. In other words: when built standalone it is +still tinyldap; when built as part of mars-nwe, the project-facing service/binary +name is `nwdirectory`. + +The planned integration requires a fork because the original code needs +mars-nwe-specific work: + +- a real CMake build, not only the original Makefile; +- standalone tinyldap build support under the tinyldap name; +- mars-nwe subdirectory build support producing the `nwdirectory` service; - LDAP/LDAPS/StartTLS integration through `nwtls`/wolfSSL; - replacement or bypass of the original flat-file storage; - later `libdirectory` and libflaim-backed storage integration; - directory schema, bootstrap, and setup integration through `nwsetup`. -Because of that, the fork should live in the repository root as `mars-tinyldap/`, -matching the existing pattern for project components that are not treated as -plain third-party libraries. The code may still document its upstream origin, -license, and local changes, but it is part of the mars-nwe component tree. +The CMake conversion should therefore support both use cases: + +```text +standalone upstream-style build: + cmake -S mars-tinyldap -B build-tinyldap + # produces tinyldap-named targets/tools + +inside mars-nwe: + add_subdirectory(mars-tinyldap) + # produces the nwdirectory service/integration target +``` The architectural relationship remains: ```text LDAP/LDAPS client - -> nwdirectory service built from mars-tinyldap + -> nwdirectory service built from mars-tinyldap/tinyldap code -> libdirectory -> libflaim-backed store ``` @@ -1203,7 +1269,9 @@ Each bundled or forked dependency should have a short mars-nwe note describing: - whether it is fixed, optional, or forked; - which mars-nwe facade owns access to it; - local changes carried by mars-nwe; -- CMake options used by the mars-nwe build. +- CMake options used by the mars-nwe build; +- whether the component supports standalone builds, mars-nwe subdirectory builds, + or both. Do not silently update third-party submodules together with unrelated functional changes. Dependency bumps should be separate patches. Forked root components diff --git a/third_party/README.md b/third_party/README.md index 0d803eb..77f31f5 100644 --- a/third_party/README.md +++ b/third_party/README.md @@ -41,6 +41,27 @@ src/nwtls_wolfssl.c Planned uses include LDAP/LDAPS/StartTLS in `nwdirectory` and any future TCP-based internal provider IPC that requires mTLS. + +## Planned: libflaim + +libflaim is the planned bundled persistent storage engine for the future +`libdirectory` store. It belongs under `third_party/libflaim` because it is a +storage engine dependency, not a mars-nwe service fork. + +The import should be mars-nwe-maintained. The initial source may come from the +SourceForge FLAIM code base or from a distro-vetted source package such as the +openSUSE `libflaim-4.9.1046` source package. The exact source, version, distro +patches, licenses, and local changes must be documented in +`third_party/libflaim/README.mars-nwe.md`. + +The original FLAIM build system should be replaced with a real CMake build, not +wrapped from the mars-nwe build. The resulting tree should build both as a +standalone library project and as a mars-nwe subdirectory, exposing a normal CMake +target such as `FLAIM::flaim`. + +FLAIM is C++ code. mars-nwe C components should not include FLAIM C++ headers +directly. Access should go through the future `libdirectory` C API. + ## Planned: zlog zlog is the planned optional advanced logging backend. If added, it should live @@ -62,6 +83,9 @@ repository root, following the existing pattern used by `admin`, `dosutils`, `mail`, and `smart`. The planned tinyldap fork is such a component. It should live as -`mars-tinyldap/` at the repository root, build the project-facing `nwdirectory` -service, gain CMake support, and later use `libdirectory`/libflaim-backed -storage instead of tinyldap's original flat-file storage. +`mars-tinyldap/` at the repository root. Its standalone identity remains +`tinyldap`, while the mars-nwe integration builds the project-facing +`nwdirectory` service. The fork should gain a real CMake build that works both +standalone under the tinyldap name and as a mars-nwe subdirectory, and it should +later use `libdirectory`/libflaim-backed storage instead of tinyldap's original +flat-file storage.