Consider extending to the stateful case

[eslick]

This is a great little library, but my use case involves a stateful worker with a simple channel into the web worker with messages coming back. It would be nice if you had a facility for standalone servants (butlers?:) that had more autonomy. The same calling convention might work, or a pair of core.async channels for input/output. LIke Brenton's recent example with Pedestal App.

[MarcoPolo]

You could probably make another 1 web worker servant pool, and interface just like before. Since you'd only have one webworker you could safely keep state.

Would that work?

[eslick]

I think that would work. However, maybe a pool of named servants? The name would be used to uniquely identify a worker that maintained a particular kinds of state and would be started with a standard call to a specific function that would set it up. Typical usage, of course, would be a single worker that maintained local state but was part of the same script. I ended up going in a different direction due to the tooling assumptions baked into Pedestal (build a separate custom script for each worker).

[MarcoPolo]

Contributions to add this in are welcome btw, I might not get a chance to add this for a while. I'm just adding things that I need.