Repository navigation
[提案] 接手 remote runtime：让 dst 连接常驻的 DSH 宿主 #1510
jakehemmerle
started this conversation in
Ideas
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
我想接手 #319 开始的 remote runtime 工作（如果项目仍然需要）。在写任何代码之前，想先请教维护者希望这个提案怎么提。
动机
dsh web（launchd/systemd），通过 Tailscale 访问。在 0.14.0 上，dst 会在自己的进程里启动一份 DSH 宿主，所以 dst 窗口用不上这个常驻宿主：没有提醒（schedule），会话随窗口关闭而停止，dst 和 web 还会争用同一份~/.dsh文件（[Bug] Concurrent dst/Web hosts overwrite each other's workspace registry (workspace.json last-writer-wins) #1451、session/writer-held）。dsh web现有的远程 API（POST /api/<ns>/<method>、/api/remote.mux）写一个客户端，协议 fixture 采自真实的 0.2.1-alpha.2 宿主。比起单独维护一个客户端，我更希望把这些经验带进 dsh-TUI。（[Bug] Option+Backspace clears the whole prompt draft; Option+←/→ move by character instead of by word #1448、[Bug] subagent/subagent_fork always fail on DSH 0.2.1-alpha: bundled presets deny schedule_* tools that the TUI never registers #1450、[Bug] Concurrent dst/Web hosts overwrite each other's workspace registry (workspace.json last-writer-wins) #1451 也是我提的。）已经读过的
#319；#115 及其指向的准入规则（TUI-RUN-001）；omdsh-dev/community#23（Runtime / Presentation / Control）；benjamin59cooper7581-afk/dsh-remote 和 Yan-Zero/dsh-remote-ssh。
问题
dsh web现有的远程 API（无需改宿主），还是像 feat: add standard remote TUI runtime #319 那样用 dsh-std 的 channel server？在提案被接受之前，我不会开始实现。
English
I'd like to own the remote runtime work that #319 started, if it's still wanted. Before writing any code, I'm asking how you'd like it proposed.
Why
dsh webpermanently (launchd/systemd) on four machines over Tailscale. On 0.14.0, dst runs its own DSH host, so a dst window can't use the long-running one: no reminders, sessions stop with the window, and dst and web contend for the same~/.dshfiles ([Bug] Concurrent dst/Web hosts overwrite each other's workspace registry (workspace.json last-writer-wins) #1451,session/writer-held).dsh web's existing remote API (POST /api/<ns>/<method>,/api/remote.mux), with wire fixtures captured from a real 0.2.1-alpha.2 host. I'd rather bring that knowledge into dsh-TUI than maintain a separate client. (I also filed [Bug] Option+Backspace clears the whole prompt draft; Option+←/→ move by character instead of by word #1448, [Bug] subagent/subagent_fork always fail on DSH 0.2.1-alpha: bundled presets deny schedule_* tools that the TUI never registers #1450 and [Bug] Concurrent dst/Web hosts overwrite each other's workspace registry (workspace.json last-writer-wins) #1451.)What I've read
#319; #115 and the admission rules it points to (TUI-RUN-001); omdsh-dev/community#23 (Runtime / Presentation / Control); benjamin59cooper7581-afk/dsh-remote and Yan-Zero/dsh-remote-ssh.
Questions
dsh web's existing remote API (no host changes), or a dsh-std channel server as in feat: add standard remote TUI runtime #319?I won't start an implementation until a proposal is accepted.
All reactions