RFC: thv serve as long-running, local process#34
Conversation
blkt
force-pushed
the
feat/long-running-local-server
branch
from
808ec5f to
a1d5e63
Compare
blkt
changed the title
thv serve as long-running HTTP serverthv serve as long-running, local process
This is work in progress.
blkt
force-pushed
the
feat/long-running-local-server
branch
from
a1d5e63 to
2321868
Compare
rdimitrov
left a comment
rdimitrov
left a comment
There was a problem hiding this comment.
I know it's a draft but definitely a +1 from me
|
|
||
| ## Non-Goals | ||
|
|
||
| - Modify existing API exposed by `thv serve` |
There was a problem hiding this comment.
Will thv servers start expose the same APIs as thv serve?
There was a problem hiding this comment.
Ideally yes, unless we have some API that breaks due to this separation.
As a rule of thumb, this RFC is not about adding features, but instead it's about designing a process that runs on the user's machine that can then hook into a remote API (if so configured).
|
|
||
| **CLI (`thv`)**: Thin client for user interaction, command parsing, and communicating with the local server via HTTP API. | ||
|
|
||
| **Local Server (`thv-server`)**: Long-running process responsible for MCP server lifecycle, configuration management, file watching, and serving as single source of truth for local state. |
There was a problem hiding this comment.
Not necessarily, I don't have strong opinions.
The thv binary might just fork, although the whole binary containing both the CLI and the HTTP server could become pretty "fat", and I don't want to rule out any benefit (or issue) we might have producing a separate binary.
There was a problem hiding this comment.
I'd suggest keeping it in the same binary for now since that eases distribution. We can revisit this later. wdyt?
4 participants
This is work in progress.