LibPolyCall v1.0.0 configuration uses Polycallfile for writable project
topology, Polycallrc for global read-only runtime defaults, and
Polycallrc.<language> for language overrides. See
docs/CONFIGURATION_STANDARD.md for load
order, validation, migration, and CLI commands. For the CLI redesign
(program-first runtime, native config, polycall_rpc v1, operation plugins)
delivered on the polycall-cli-redesign branch, start with
docs/CLI.md and the quick start below.
# build (GNU Make and CMake are independent; either is enough)
make BUILD_DIR=build/linux-gcc CC=gcc all test
# or: cmake -S . -B build/cmake -DBUILD_TESTING=ON && cmake --build build/cmake --parallel && ctest --test-dir build/cmake
# help / version / doctor never touch the network or start anything
build/linux-gcc/bin/polycall --version
build/linux-gcc/bin/polycall doctor
# start the runtime in the foreground, on an ephemeral port
build/linux-gcc/bin/polycall start --endpoint 127.0.0.1:0 &
# call a registered operation through it (docs/RPC.md)
build/linux-gcc/bin/polycall call inventory get --endpoint 127.0.0.1:<port> \
--input-value '{"item_id":"widget-a"}'
See docs/CLI.md for the full command reference, docs/NATIVE_CONFIG.md for language-native configuration, docs/RPC.md for the wire protocol, docs/PLUGINS.md for loading operations without a core rebuild, and docs/PLATFORM_REPORT.md for exactly what has and hasn't been verified on which platform.
start --daemon detaches the runtime into the background and returns
immediately, printing the detached process's PID:
# Windows
.\build\windows-cmake\bin\Release\polycall.exe --project-root . --config .\Polycallfile start --daemon# Linux / macOS
build/linux-gcc/bin/polycall --project-root . --config ./Polycallfile start --daemon--project-root controls where the telemetry sink
(.polycall/telemetry.jsonl) and any relative --endpoint-file/--load
paths resolve; --config is accepted as a global option here but has no
effect on start itself (it's read by config validate/config show).
Learn the daemon's bound address with --endpoint-file PATH, and shut it
down cleanly with polycall stop --endpoint host:port. On POSIX this is a
standard double-fork detach; on Windows, which has no fork(), it re-execs
the same binary with DETACHED_PROCESS. See
docs/CLI.md and
docs/CHANGELOG.md for the full contract.
For too long, we've accepted the fragmentation of our digital ecosystem. Python talks to Python. Node.js whispers to JavaScript. Java shouts in its own dialect. Meanwhile, developers waste countless hours building bridges between languages, creating duplicate APIs, and maintaining separate implementations for what should be unified solutions.
This ends now.
LibPolyCall represents a fundamental shift from "binding-first" to "program-first" architecture. While others build language-specific solutions, we've created something unprecedented: a single protocol that makes language barriers obsolete.
Think about it: Why should your brilliant algorithm be imprisoned in one language? Why should your API exist in five different implementations? Why should your microservices struggle to communicate because they weren't born speaking the same dialect?
The answer is simple: They shouldn't.
In a world where security breaches make headlines daily, LibPolyCall implements zero-trust architecture at its core. Every component, every connection, every data exchange is validated, encrypted, and monitored. We don't just connect systems—we create secure, intelligent networks that think before they trust.
Our cryptographically-seeded GUID system doesn't just track state; it creates perfect reproducibility. Every bug becomes a learning opportunity. Every interaction becomes intelligence. Every problem becomes solvable.
Traditional systems are blind. They process requests without understanding context, handle errors without learning from them, and scale without intelligence.
LibPolyCall sees everything:
- Silent protocol observation captures every interaction
- Real-time analytics reveal patterns others miss
- State machine mapping creates complete user journey intelligence
- Bug replication makes impossible problems possible to solve
This isn't just monitoring—this is system consciousness.
Because the enterprise world is drowning in complexity:
- Legacy COBOL systems that can't retire
- Microservices that don't actually communicate
- APIs that exist in silos
- Development teams speaking different technical languages
We've built the universal translator for code.
Every hour your team spends building language-specific APIs is an hour not spent on innovation. Every duplicate implementation is technical debt accumulating interest. Every integration challenge is opportunity cost mounting.
LibPolyCall eliminates this waste through polymorphic core architecture:
- One API definition → Multiple language implementations
- Unified debugging → Faster problem resolution
- Centralized telemetry → Intelligent scaling decisions
- Program-first design → Technology-agnostic solutions
Imagine deploying a single API specification that instantly works across Python, Node.js, Java, Go, and languages not yet invented. Imagine debugging production issues with perfect state reproduction. Imagine microservices that communicate as naturally as neurons in a brain.
This isn't imagination—this is LibPolyCall.
LibPolyCall represents years of research into:
- Polymorphic protocol design
- Cross-language FFI optimization
- Zero-trust security architecture
- Advanced telemetry systems
- State machine intelligence
We've solved problems others didn't know existed. We've built bridges to futures others can't envision.
The fragmented API ecosystem is a solved problem—if you choose to solve it.
The security challenges of microservice communication are conquered—if you embrace zero-trust architecture.
The debugging nightmare of distributed systems is over—if you implement intelligent telemetry.
The future of unified, secure, intelligent system communication is available now.
LibPolyCall: Where program-first architecture meets zero-trust security meets intelligent telemetry.
Repository: obinexus/polycall (github.com/obinexus/polycall)
The future is now. The choice is yours.
Nnamdi Michael Okpala
Founder & Chief Architect
OBINexusComputing
"In a world of language silos, be the universal protocol. In an age of security breaches, be the zero-trust solution. In an era of blind systems, be the intelligent observer. The future isn't coming—it's here, and it's written in C."
Delivered on the polycall-cli-redesign branch: one predictable CLI
contract, a typed native configuration model alongside the legacy loader,
the polycall_rpc v1 wire and a real cross-language operation runtime, an
operation-plugin loader (run --load, no core rebuild), and
polycall_rpc v1 clients for Node.js, Python, Go and Java, verified with a
cross-language conformance harness. See
docs/IMPLEMENTATION.md for the full account and
docs/PLATFORM_REPORT.md /
docs/CONFORMANCE.md for what was actually verified,
on which platform, and what was not.
Version numbering note: the library/ABI version has read 1.0.1
throughout (include/polycall_export.h is the canonical source; src/polycall.c
derives its reported version from it rather than a separately hardcoded
string, so the two cannot drift). The "Version 1.1.0" entry directly below
was a documentation label recorded alongside an earlier merge and was never
matched by an actual library-version bump -- it's kept here as the
historical record, not as a claim that 1.1.0 ever shipped.
- COBOL Binding: Enterprise mainframe integration via cbl-polycall
- Unified Codebase: Merged polycall repository into libpolycall
- Enhanced Build System: Improved CMake configuration
- Expanded Documentation: Legal framework and DOP architecture docs
- Original polycall v1 preserved in
polycall-v1/directory - All bindings now in unified
bindings/structure - See MIGRATION_REPORT.md for full details