Local and remote execution with one generated model
Documentation status: architecture — see Maturity and evidence.
The binding architecture is intended to preserve the same generated .NET object model across local and remote Runtime topologies.
C# / F# application
|
v
Generated .NET API
|
v
IClientRuntime
| |
v v
Native adapter RPC adapter
| |
ABI identity ABI identity over RPC
| |
+------ logiCells Runtime ------+
What stays the same
The generated surface should preserve:
- public type and member names;
- method/property semantics;
- stable generated
TypeId/MethodIddescriptors; - object-reference semantics;
- normal .NET values for strings, numbers, arrays, and generated objects.
What changes with topology
The transport owns topology-specific mechanics.
A local adapter converts generated calls to the native ABI and manages native handles and buffers. A remote adapter serializes the same invocation identity into RPC requests, resolves remote object references, and applies session, timeout, correlation, and release semantics.
Latency also changes the efficient call shape. A remote application should prefer coarse-grained operations, projections, and batching over large numbers of fine-grained property calls.
Object lifetime
Local generated objects can wrap opaque native handles. Remote generated objects instead carry an InstanceId lease associated with type metadata and a session.
Both should project to deterministic disposal/release semantics in .NET. Application code should not need to distinguish the native pointer from the remote instance identifier.
Capability negotiation
Remote endpoints expose ABI/runtime version and capability discovery. Generated clients should use that information to fail early when a member or mode is unavailable.
Status
The supplied generator and RPC sources support this architecture directly. Full behavioral parity is still capability-dependent, so the programming model is documented as architecture until the same generated contract tests are certified against both adapters.