Search theclapp.blog-city.com
Remote agent doesn't really need that much plumbing
I eventually realized that Lispworks has a very nice interface to Unix processes called run-shell-command. You can even redirect STDERR, unlike some other Lisps *cough*clisp*cough*. So instead of trying to build some elaborate Lisp functions, I should build a Unix command called "on" or something that runs a command on some other server via the remote agent, and invoke on via run-shell-command. I can build on in Lisp, certainly, and I can build some macrology around run-shell-command to make it a bit easier to use from a repl prompt, but it doesn't have to be nearly as hard as I was making it.
Now I just have to figure out a good way to talk to the remote agent. I'd kind of like to leave it running on the remote end and reconnect to it, like you can do with screen, but a) I guess there's no real reason to do that, and b) if I did do it that way, then it'd have to either listen to a network socket that anybody could connect to (ick), or a fifo that only I could talk to, and if I do that (the fifo), then I have to, well, deal with the complexity of fifos. Not that said complexity is that high, but given point (a) to begin with, why bother?
So I guess the remote agent will just listen to STDIN and write to STDOUT & STDERR, and I'll run it via ssh, and if my VPN drops, it'll die, and I'll restart it. That is, on will restart it, automatically, behind the scenes. And on will probably talk to the local side via a network socket ... or a fifo ... and now I'm kind of wondering, if I'm going to do fifos anyway, maybe I should just do them remotely. Hmmm ...
No, even if I need fifos locally, I don't need them remotely.
This will require a bit more design work for both ends. I have to think about security (other people trying to connect to my socket or fifo or whatever) and concurrency (running multiple commands on the same server at the same time).