docs(research): remove hedging language from alknet-ssh and alknet-tty research
- alknet-ssh: remove paragraphs describing old hedging problem in channel decomposition section and DP-4 — state the insight directly - alknet-tty: replace 'defer for v1' / 'reserved for future use' with 'not needed for the current scope' in OQ-TTY-02
This commit is contained in:
@@ -71,14 +71,9 @@ copied and also since rewritten.
|
|||||||
|
|
||||||
## The Channel Decomposition (Core Insight)
|
## The Channel Decomposition (Core Insight)
|
||||||
|
|
||||||
The initial research framed alknet-ssh's scope as a single massive v1: server
|
SSH's channel multiplexer is the natural decomposition point. The features
|
||||||
+ client + SOCKS5 + bidirectional port forwarding, all at once. That framing
|
that make up alknet-ssh are layers that stack on top of it — each functional
|
||||||
made the crate feel unmanageably large and produced hedging language
|
on its own.
|
||||||
("v1 default," "can be revisited later," "two-way door, decide later") that
|
|
||||||
proposed shipping non-functional or half-built versions. This revision
|
|
||||||
dissolves that problem by recognizing that **SSH's channel multiplexer is the
|
|
||||||
natural decomposition point**, and the features that felt like a massive scope
|
|
||||||
are layers that stack on top of it — each functional on its own.
|
|
||||||
|
|
||||||
### How SSH channels work
|
### How SSH channels work
|
||||||
|
|
||||||
@@ -427,8 +422,7 @@ choice in the ssh spec.
|
|||||||
### DP-4: Client + forwarding + SOCKS5 + SFTP scope — reframed as layer order
|
### DP-4: Client + forwarding + SOCKS5 + SFTP scope — reframed as layer order
|
||||||
*(Recommended: one-way door on "all in alknet-ssh"; two-way door on extraction)*
|
*(Recommended: one-way door on "all in alknet-ssh"; two-way door on extraction)*
|
||||||
|
|
||||||
The initial research framed this as "is all of this in v1?" — a massive scope
|
The channel decomposition answers the scope question. The question is not "do we
|
||||||
question. The channel decomposition dissolves it. The question is not "do we
|
|
||||||
ship it all at once" but "what's the build order, and are all the layers in
|
ship it all at once" but "what's the build order, and are all the layers in
|
||||||
alknet-ssh?"
|
alknet-ssh?"
|
||||||
|
|
||||||
|
|||||||
@@ -546,9 +546,10 @@ channel and PTY-specific paths.
|
|||||||
extension informs the decision.
|
extension informs the decision.
|
||||||
- **OQ-TTY-02 (terminal modes)**: SSH's `pty_request` carries TTY modes
|
- **OQ-TTY-02 (terminal modes)**: SSH's `pty_request` carries TTY modes
|
||||||
(echo, raw, canonical, etc.) as a packed bitmask. Does alknet-tty
|
(echo, raw, canonical, etc.) as a packed bitmask. Does alknet-tty
|
||||||
support these, or defer to the backend's defaults? Likely defer for v1
|
support these, or use the backend's defaults? The common case is
|
||||||
(the common case is "default terminal modes"); the `modes` field in
|
"default terminal modes" — the `modes` field in `TerminalParams` is
|
||||||
`TerminalParams` is reserved for future use.
|
reserved for when a concrete use case requires mode control. Not
|
||||||
|
needed for the current scope.
|
||||||
- **OQ-TTY-03 (flow control)**: the chunk format has no windowing (QUIC
|
- **OQ-TTY-03 (flow control)**: the chunk format has no windowing (QUIC
|
||||||
provides flow control on the bidi stream). Is this sufficient for
|
provides flow control on the bidi stream). Is this sufficient for
|
||||||
high-throughput stdout (e.g., `cargo build` output)? QUIC's per-stream
|
high-throughput stdout (e.g., `cargo build` output)? QUIC's per-stream
|
||||||
|
|||||||
Reference in New Issue
Block a user