Ideal workflow for dynamic indexing jobs

[Quantumplation]

One thing that's slightly awkward about kupo right now is the workflow for dynamic workloads.

It's often the case that I have a kupo instance that is indexing some patterns, and I'd like to add a new pattern to this.

1. this interferes with other products that are already using kupo, as kupo has to stop and reindex, and can't answer queries for other tokens while it does so
2. it's a little inconvenient to codify this in an "infrastructure as code" sense; if I add something new to the docker compose file, kupo complains; and if I add it via API, my docker-compose is now out of sync.
3. it requires extra orchestration for the products built on top of kupo to know whether they can rely on the query or not

I know the current kupo philosophy / infrastructure restricts what is reasonably implementable, but in the interest of providing some discussion around future features/products, I thought I would lay out what my ideal workflow might look like; maybe this will inspire some ideas even if they don't look exactly like this.

• Every service built on top of kupo announces, on connection, what it "cares about": the patterns, and an optional point (or range of points) they they want sync'd
• Kupo knows whether or not it has coverage for that, both in terms of patterns (is this pattern, or a superset covered) and time (for that pattern, did we start/stop indexing in a superset of that range)
• If so, it responds with a thumbs up and we can continue about our day; this gives us a nice infrastructure-as-code approach where each service can be deployed/restarted dynamically without having to worry about whether it's been booted before or not
• If not, it either holds the connection open, or responds with some kind of job identifier, but the downstream service knows not to proceed until kupo has indexed the appropriate state
• Kupo starts, in the background, an alternate sync'ing thread; the existing thread continues to keep up to date with the tip of the chain, and accurately answer queries for other services, until the background thread catches up and can be merged into the main thread
• once that background sync job is complete, the downstream service that was waiting on it can continue on it's merry way, querying as appropriate

Like I said, this is a pretty tall glass of water, so maybe it makes more sense as a coordination service on top of kupo, that dynamically spawns and terminates kupo instances, and routes queries to the instance that can answer the query.

Hopefully this perspective from a heavy kupo user helps; I still love kupo lots so far :)