Updater script specifics

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:

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.

— Cadence

← Previous: Byte length discoveriesNext: Amanda designs →