Decision record
docs/decisions/17670-bidi-implementation-boundaries.md (#17670)
Binding implementation
Each binding currently exposes the BiDi implementation off the driver and fails conformance;
bringing it in line is a deprecation-policy change, not a straight removal.
Notes
Scope per binding (from the record's "Current behavior" table — what conformance requires):
| Binding |
Non-conforming today |
Convergence target |
| Java |
Driver exposes the raw BiDi connection (HasBiDi.getBiDi()); protocol types are public |
Deprecate HasBiDi.getBiDi(), mark protocol types internal, reach the low-level layer only by composing it with the driver |
| Python |
driver.network / driver.script return the low-level bidi-namespaced modules |
Return protocol-neutral wrappers from driver.network / driver.script; mark the bidi modules internal |
| Ruby |
Driver exposes a BiDi accessor (driver.bidi) |
Deprecate driver.bidi; expose the low-level layer only via composition (BiDi::Protocol::Network.new(driver)) |
| .NET |
Driver extension returns a BiDi type (AsBiDiAsync() → IBiDi) |
Internalize the BiDi type; reach it by composition, not off the driver |
| JavaScript |
Driver exposes a BiDi accessor (driver.getBidi()) |
Deprecate driver.getBidi(); expose the low-level layer only via composition |
Marking a surface Beta does not satisfy decision 2 — Beta signals an API becoming supported,
the opposite of internal — so Beta is not an acceptable "internal" convention in review.
Related, tracked separately: all bindings expose a BiDi-named enable option (enableBiDi /
enable_bidi) that the record notes should become protocol-neutral. This overlaps the open
enable_sockets naming discussion, so it is deliberately not checklisted here — it belongs to
whichever record settles that naming.
Decision record
docs/decisions/17670-bidi-implementation-boundaries.md (#17670)
Binding implementation
Each binding currently exposes the BiDi implementation off the driver and fails conformance;
bringing it in line is a deprecation-policy change, not a straight removal.
Notes
Scope per binding (from the record's "Current behavior" table — what conformance requires):
HasBiDi.getBiDi()); protocol types are publicHasBiDi.getBiDi(), mark protocol types internal, reach the low-level layer only by composing it with the driverdriver.network/driver.scriptreturn the low-levelbidi-namespaced modulesdriver.network/driver.script; mark thebidimodules internaldriver.bidi)driver.bidi; expose the low-level layer only via composition (BiDi::Protocol::Network.new(driver))AsBiDiAsync()→IBiDi)driver.getBidi())driver.getBidi(); expose the low-level layer only via compositionMarking a surface Beta does not satisfy decision 2 — Beta signals an API becoming supported,
the opposite of internal — so Beta is not an acceptable "internal" convention in review.
Related, tracked separately: all bindings expose a BiDi-named enable option (
enableBiDi/enable_bidi) that the record notes should become protocol-neutral. This overlaps the openenable_socketsnaming discussion, so it is deliberately not checklisted here — it belongs towhichever record settles that naming.