Known Limitations And Beta Gaps
This page is intentionally plainspoken. libLogit is promising a portable
logging SDK, and Beta credibility depends on being explicit about what is still
uneven.
Current Truth
libLogit already proves the LOGIT model across the Alpha MVP languages, but
the project is not yet fully language agnostic in the strict sense.
What exists today:
- direct logger construction in the Alpha baseline languages
- structure-fed configuration
- shared JSON config loading
- console output
- local file output
- remote-path-as-file output
- text output
- JSON-lines output
- shared conformance fixtures
- a Python reference implementation with SQLite storage and viewer tooling
What is not yet true everywhere:
- identical advanced feature support across all bindings
- published production-grade packages for every ecosystem
- full Windows, Linux, and macOS release evidence for every binding
- stable consumer install documentation for every binding
- real network transport support beyond filesystem-like remote paths
Important Binding-Specific Gaps
Python
- Most complete binding.
- Advanced features such as redaction, buffering, failure policy, SQLite
retention, and viewer integration are strongest here.
- The remaining gap is cross-binding parity, not basic functionality.
C And C++
- Core logger flow is proven.
- Packaging and installed-consumer experience are improving, but still need
broader environment validation.
- C++ config loading depends on
nlohmann/json.hpp, which needs a clean and
predictable consumer story on all supported platforms.
C#, Java, JavaScript, Go, Kotlin
- Core logger behavior is present.
- Conformance is present for the current baseline fixtures.
- Explicit logger-level
flush() / close() lifecycle parity is not yet part
of the public baseline for these bindings.
- Package publication, public install docs, and long-tail ecosystem polish are
still Beta work.
Error And Unsupported-Field Reality
The repo now has a clearer Beta direction for setup failures:
- invalid config shape should fail fast
- unknown levels should fail fast
- contradictory path settings should fail fast
- unknown sinks should fail fast
- unsupported advanced fields should not be silently claimed
What is still uneven is not the direction, but the depth of implementation and
surface polish across bindings. Python has the strongest validation and error
coverage today.
Product-Level Gaps To Close Before Beta
- Freeze the shared
LOGIT contract in spec and docs.
- Expand shared fixtures to cover more than the baseline cases.
- Publish or fully prepare public package install paths for supported
bindings.
- Validate the package and conformance matrix on multiple operating systems.
- Make the viewer/database workflow feel like an intentional product feature,
not just a reference implementation sidecar.
- Decide the scope of real remote transports for Beta versus post-Beta.
- Keep unsupported-field and setup-error behavior coherent across supported
bindings.
What Users Should Safely Assume Today
You can safely evaluate libLogit as:
- a portable logging object model
- a strong Python-first reference SDK
- a credible cross-language alpha baseline
- a project actively hardening toward Beta
You should not yet assume:
- every listed language has the same advanced runtime behavior
- every ecosystem has a polished public package install story today
- real remote transport support is finalized
- the Beta support matrix is already closed
Where To Track Closure