Problem
ConnectionSettings (vox-types/src/message.rs) is a plain #[derive(Facet)] struct constructed via struct literals (ConnectionSettings { parity, max_concurrent_requests, initial_channel_credit }) in ~55 sites across vox-core (session, handshake, builders, golden-vector tool) and the test suites.
It has no Default and no builder, so adding any field is a breaking, high-churn change: every literal must be edited, and the diff drowns the actual feature in mechanical noise. This already bit initial_channel_credit (added with #[facet(default = …)] so the wire stays back-compatible, but every Rust constructor still had to be touched).
Concretely: while adding vox::Fd / SCM_RIGHTS fd-passing, the natural place to advertise the peer-software capability is ConnectionSettings.fd_passing: bool (schema-evolvable via #[facet(default = false)]). That single field is correct and idiomatic at the schema layer — but it would require mechanically touching ~55 unrelated struct literals, so it had to be deferred even though the design called for it.
Proposal
Give ConnectionSettings a builder / Default-based construction so capability/limit fields can be added without a codebase-wide sweep:
ConnectionSettings::new(parity) returning sensible defaults, plus .max_concurrent_requests(n) / .initial_channel_credit(n) / future .fd_passing(true) chained setters; or
- a
#[non_exhaustive] + ConnectionSettings { ..ConnectionSettings::default_for(parity) } pattern (parity has no meaningful default, so a default_for(parity) constructor is probably the cleanest seam).
Either way the goal: adding a future capability field is a one-line change to the struct + the builder, not a ~55-site mechanical edit.
Notes
- Keep
#[facet(default = …)] on new fields so the wire format stays back-compatible with older peers (older peers omit the field → default).
- Migrating the existing ~55 sites is itself a mechanical-but-large change; doing it once via the builder pays for itself the next time a field is added (fd-passing being the immediate motivating case).
Filed while implementing vox::Fd fd-passing (downstream: stax privileged Linux profiler daemon).
Problem
ConnectionSettings(vox-types/src/message.rs) is a plain#[derive(Facet)]struct constructed via struct literals (ConnectionSettings { parity, max_concurrent_requests, initial_channel_credit }) in ~55 sites acrossvox-core(session, handshake, builders, golden-vector tool) and the test suites.It has no
Defaultand no builder, so adding any field is a breaking, high-churn change: every literal must be edited, and the diff drowns the actual feature in mechanical noise. This already bitinitial_channel_credit(added with#[facet(default = …)]so the wire stays back-compatible, but every Rust constructor still had to be touched).Concretely: while adding
vox::Fd/ SCM_RIGHTS fd-passing, the natural place to advertise the peer-software capability isConnectionSettings.fd_passing: bool(schema-evolvable via#[facet(default = false)]). That single field is correct and idiomatic at the schema layer — but it would require mechanically touching ~55 unrelated struct literals, so it had to be deferred even though the design called for it.Proposal
Give
ConnectionSettingsa builder /Default-based construction so capability/limit fields can be added without a codebase-wide sweep:ConnectionSettings::new(parity)returning sensible defaults, plus.max_concurrent_requests(n)/.initial_channel_credit(n)/ future.fd_passing(true)chained setters; or#[non_exhaustive]+ConnectionSettings { ..ConnectionSettings::default_for(parity) }pattern (parity has no meaningful default, so adefault_for(parity)constructor is probably the cleanest seam).Either way the goal: adding a future capability field is a one-line change to the struct + the builder, not a ~55-site mechanical edit.
Notes
#[facet(default = …)]on new fields so the wire format stays back-compatible with older peers (older peers omit the field → default).Filed while implementing
vox::Fdfd-passing (downstream: stax privileged Linux profiler daemon).