Thanks for taking note and leaving a question, much appreciated. I’m looking to actively start on ruote-kit by mid-April. Our biggest project is nearing completion, and it uses ruote-rest extensively for managing our processes. So I’ll make sure migrations from ruote-rest to ruote-kit will be a smooth one (which should be since all the processes, expressions, workitems, etc lives inside the engine).

As for interopt, my main focus is gonna be on exposing ruote-kit to developers of other languages and soliciting them into writing 1) RESTful clients for ruote-kit and 2) plugins for popular frameworks. Clients should be light but also encapsulate some of what ruote has to offer…

To make a long story short, we can discuss this in length on the mailing list, ruote-kit will not be much different from ruote-rest when you look from the outside. It will however focus on easy deployments, easy upgrades, more flexible configurations and some other minor tweaks. We hope to provide some extra tools to make prototyping and testing of processes easier as well… The biggest bonus for us all is that it frees John up to work on enhancing the engine itself

I have followed some of your posts on the ruote mailing list. I have worked with John a bit and am ramping up on some ruote development, particularly ruote-rest. I would be interested to know more about your thoughts for ruote-kit, particularly the python interoperability as this will be my primary focus. What sort of timeline are you looking at for developing this and what structure do you envision for the client libraries?