ruote-kit ramblings
Intro:
A rewrite of the existing ruote-rest project that aims to provide an easy to deploy and maintain ruote instance, accessible using a RESTful interface. Should be a breeze to use for non-Ruby projects and developers (apart from Ruby process definitions).
Architecture:
* Rack based, possibly a sinatra app
* Daemon-kit file system layout, keep ruote & co away from local libs, participants, configuration
* Easily “vendor everything” for simple deployments and maintenance
* Easy backups (simple rake task)
* Multiple storage backend, give people what they are comfortable with
* Fast, fast, fast
* Multiple environment support (development, test, production, etc)
* Custom resource implementations/enhancements
* ‘public’ folder for local assets that might be used by consumers
Complimentary stuff
* Client gem for hooking into Rails (or any other Ruby project)
* Python client library
* Java client library
Features:
* Completely RESTful (but without all the lingo)
* Visualization of processes
* Flexible searching (workitems, processes, etc)
* Open to other languages
* Integrated testing tools
* Edit process definitions on the fly
* Comprehensive and clear logging
Supporting eco-systems:
* Site to share process definitions
* Lighthouse
* Separate mail list? Might cause confusion with existing users (-1 currently)
Starting out:
1. $ gem install
2. $ /path/to/project
3. Rejoice
Project layout:
+ bin
+ config
+ lib
+ participants
+ public
+ resources
+ script
+ vendor
+ route
+ gems
Capfile
Rakefile
2 comments
Kenneth,
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?
by Nick on March 18, 2009 at 7:36 pm. #
Nick
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
by Kenneth Kalmer on March 19, 2009 at 1:36 pm. #