I use fish shell ><> because it's really good for both interactive use and scripting. Thanks fish developers!
I'm planning to use it to write the Bibliogram updater script because it's fun.
The way this will work is the main instance will be connected to a GitHub webhook, which will send a request to the server when a new commit is pushed. The main server can then broadcast to all connected clients that there is a new update. I think this will be very good for getting updates straight away.
Clients can connect to the main instance using event streams, which is basically just a stream of almost-plaintext over HTTP. This means it's instant, unlike polling, and it's uncomplicated to use on the command line, unlike something like websockets.
I do realise that this might be a bit over-engineered, but I think it's better than the alternatives:
- RSS feeds (does GitHub have RSS?) The thing with RSS is that the full content is sent each time, so I'd have to add everything to some sort of store on disk and check against that store. Possible, but I think it could get messy. RSS is also a few minutes slow because it's polling, though this doesn't matter.
- A webhook connected to each instance. This would require the server to be directly addressable on the web (private instances behind NAT are not). Also, GitHub doesn't let you set up webhooks if you aren't a manager of the repository.
So that's why I've chosen this system. Let me know if you have an idea which would be better.
The idea is for the updater script for the other instances to connect to the event stream that bibliogram.art provides, and once bibliogram.art receives the webhook from GitHub that there's an update, it'll let all the connected instances know instantly via the event stream. The script can pipe the HTTP response into
grep -m 1 to pause until the event happens.
I think then I'll have the script run Bibliogram as a background job (with
&) and then once the script receives the notice it can kill the job, git pull, npm install, and start up again.
A different idea that I can consider is Bibliogram connecting to the event stream itself and exiting when it receives the event, which means I don't have to deal with shell scripts being obtuse (as much as I love fish, there's some kinds of logic that shell scripts just have trouble expressing neatly).
Lots of thinking today.