Right now it can only start and stop the server once, due to a known
bug. Eventually I'd like it to be a user-friendly GUI with all the
required config files and maybe a folder browser so you can pick
which folder(s) are served.
It doesn't work on Android, and I can't fault it for that (Platform difference)
but it also drags in `uom` which has a bunch of template magic that takes
forever to compile, and I'm pretty sure it's dragging down my compile times.
I tried to build `ptth_server` on nightly to get compile timings, and heim
depends on `socket2` which failed to compile.
And I never ended up using the CPU monitoring. So heim is gone now.
The password checking is not necessary with the new process of generating
high-entropy Base64 passwords and then approving them on the relay.
The password file takes a lot of space and this doesn't need to be part
of ptth_server's public API, if there is one, anyway.
I forgot to set the version in Cargo.toml files for 1.0.0.
I'm not gonna do 0.x versions because this is already live somewhere
and I don't like that 0.x adds complexity to versioning.
There's a lot of missing pieces, but the big picture is like this:
- Use 2 completely separate HTTP streams, and try to keep them alive as long
as possible, each in basically half-duplex mode
- Each stream has a long-running PUT and GET, sort of like station307
- Each end has to be terminated by a native app that either connects to a local
TCP server, or acts as a local TCP server
- No clue how it would work for multiple connections on the same port. Poorly,
I guess?
- It's probably gonna run like garbage because we're splitting TCP into
2 TCP streams, and although backpressure might work, the ACKs will be less
efficient. And the congestion control might get confused
My only goal is to tunnel Tracy over it, so that I can have that remotely.
The new method is much nicer and doesn't require the manual make-old-git
step. The top-level command is actually build_and_minimize.bash, which uses
`git archive` to unpack the last Git commit and build with _that_ Dockerfile
and Docker context. This is better for determinism. It's similar to our build
process for that one big project at work.
_