API stability roadmap

[cdnsteve]

Morning,

Just wondering if there is a roadmap where API stability will be set?

Thanks!

[iamduo]

There isn't a detailed roadmap yet, but there is a tiny "What is left" roadmap here: https://github.com/iamduo/workq#roadmapped . It may be more of a rolling roadmap for the time being though. When this roadmap becomes too unwieldy, I'll branch it out into its own doc. The most glaring gap at the moment is the lack of persistence which does not affect the protocol itself however.

There will need to be some time to ensure there are no glaring gaps in the protocol itself. For example, not enough flexibility with certain commands...etc. Were you looking for anything in particular in the meantime?

[cdnsteve]

Cool. I was just thinking of a Python client, but client dev likely won't want to begin until the protocol/API is in a near stable point. I like the idea of planning for the interface of the back-end storage so then if anyone wants to use something like Redis, etc, it's easy. If you are looking for some input I'd be happy to. Maybe a new github issue to spec it out would be the preferred way?

[iamduo]

cdnsteve,
Give me some time to review the use case, the problem with the storage pluggability case isn't that it would be difficult to add, but the maintenance overhead of the pluggability since it probably has to be built into Workq along with the many others users would request.

A good feature of Workq is that it can standalone without any other external dependencies especially a networked one (even though it would be optional). I would like to concentrate on making this shine first before thinking about pluggability. It would just add more complexity too soon. Hope that makes sense.

Feel free to dig around though, I think (I hope) it would be "relatively" easy to prototype for fun.