Usage
Taskhoster hosts durable task queues on your own box. You stand up the server once, run the local package on your machine to mirror your definitions up, and declare each queue as a file in a folder named for its domain. From then on producers post tasks and watch them, while workers claim tasks and complete them. Every task is a file on disk, and a careful lifecycle makes sure nothing gets stuck.
task.example.com/ a queue host (a domain)
taskhoster-queues/
resize.json the "resize" queue → endpoint /resize on that domain
thumbnail.json another queue — its own endpoint and sockets
taskhoster-users/
alice.json a user — a name and a token, listed in access rulesContents
Server →
Stand up the server on a fresh box: one bootstrap command, what it installs, and how to point a queue domain at it.
Local →
The local package: its config.json, mirroring your queues up with one command, and
the three log browsers.
Queues →
Defining a queue: the folder layout, the three schemas, the access rules, and every setting that governs its lifecycle.
Producers →
Posting tasks, reading their status, and watching them move on the monitor WebSocket.
Workers →
Claiming by capability with the criteria language, reporting progress, and posting results, over HTTP or a worker socket.
Lifecycle →
The heart of it: states, leases, re-queues, late-but-useful results, queue timeout and retention.
Users →
Who may post, read and work: a domain's users, and per-queue rules that list which of them (and whether the public) may do each thing.
Upgrades →
Evolving a queue safely: adding fields, changing settings, and what happens to items in flight.