On Thu, Dec 10, 2009 at 9:42 AM, sjampster <[email protected]>wrote:
> Hi Kenneth, > > Thanks for your thorough explanation. I see that I was thinking in the > right direction: launching ruote processes from within state > transitions. > > I agree with you that a pure statemachine which should handle the > process you describe, will collapse on itself. The sheer amount of > states and transitions is too big to handle. I have a lot of > experience with this in a program of mine, and that's why I am looking > for a better way to do things for the next version. In my current > program a lot of feature- and customer requests have to be added > constantly, and this has become a nightmare at this point. > > I was wondering: does the ruote process call the transition in your > example? > In my case I'm running ruote-rest (to be replaced with ruote-kit) separately from the rails application containing the models and state machines. My transitions are called via REST from a special participant. With that said, if ruote and the models are in the same process nothing stop you from having a small participant that is only responsible for managing the transitions (and handling errors from the guards). > The other question I have is, should I stick with ruote <1.0 or is it > a good idea at this point to switch to 2.x? > I'm with John here, go with 2.0 or 2.1. For my production use, and a project I'm working on with John, we'll be going ruote-kit 2.1, thus leapfrogging 2.0 all together. Best -- Kenneth Kalmer [email protected] http://opensourcery.co.za @kennethkalmer -- you received this message because you are subscribed to the "ruote users" group. to post : send email to [email protected] to unsubscribe : send email to [email protected] more options : http://groups.google.com/group/openwferu-users?hl=en
