ruote log_2010-02-03

2010-02-03 13:23:48 utc anb_ Hello
2010-02-03 13:36:51 utc tosch_le hi
2010-02-03 13:48:09 utc anb_ I'm playing with ruote, ruote-kit and ruote-couch and I have a "design" question
2010-02-03 13:48:37 utc anb_ I am aiming at a standalone workflow engine that I could query through a rest interface,
2010-02-03 13:49:14 utc anb_ and I don't know if I should use ruote-kit or if using couchdb and it's rest api is enough
2010-02-03 13:50:01 utc anb_ of course I just need a worker thread somewhere
2010-02-03 13:50:21 utc tosch_le hmm. i'm not much in ruote-couch so i suppose i can't answer your question properly, sorry.
2010-02-03 13:50:42 utc anb_ no problem :) thanks for trying
2010-02-03 13:51:08 utc anb_ maybe I should go with both. are you familiar with ruote-kit ?
2010-02-03 13:51:19 utc tosch_le fairly well.
2010-02-03 13:51:48 utc anb_ what I miss in it is the ability to search through running processes by variables
2010-02-03 13:51:54 utc tosch_le ruote-kit will be even a fine tool to peep into the running processes of ruote
2010-02-03 13:52:06 utc anb_ for example, to find every processes that has a variable customerId with value 99938
2010-02-03 13:54:03 utc anb_ so I could use route-kit as the worker thread and process API and couchdb for complex queries
2010-02-03 13:54:21 utc tosch_le hey, a feature request!
2010-02-03 13:54:41 utc anb_ hehe
2010-02-03 13:55:11 utc tosch_le you could:
2010-02-03 13:55:13 utc tosch_le a) fork kenneth' repo and implement the feature
2010-02-03 13:55:15 utc tosch_le or
2010-02-03 13:55:17 utc tosch_le b) just open at ticket at
2010-02-03 13:55:19 utc tosch_le ;-)
2010-02-03 13:55:50 utc tosch_le what do you mean with "use rk as the worker thread"?
2010-02-03 13:57:25 utc anb_ I mean couchdb is just storage, I need a worker so instead of writing a little ruote deamon, I can use ruote-kit to use couchdb as storage ... no ?
2010-02-03 14:00:37 utc tosch_le ok, let's sort this engine, storage and worker thing out. it's true, you need one ore more running workers somewhere or you're processes will be stalled. so ruote = engine(s) + storage + worker(s). running a worker is pretty easy, you won't need rk for that and rk needs a always-on-worker anyway
2010-02-03 14:01:54 utc anb_ all right
2010-02-03 14:02:07 utc anb_ and multiple workers is fine too ?
2010-02-03 14:02:24 utc tosch_le have a look at the "running workers" section in the rk readme.
2010-02-03 14:02:36 utc tosch_le yes, multiple workers are fine, too.
2010-02-03 14:02:45 utc anb_ ok, thanks for the clarification
2010-02-03 14:03:34 utc anb_ are you Torsten ?
2010-02-03 14:03:37 utc tosch_le yes.
2010-02-03 14:11:29 utc tosch_le i suppose accessing ruote's data directely from the couch when using ruote-couch is possible, but not necessarily advisable.
2010-02-03 14:12:45 utc tosch_le patching/extending/improving ruote-couch would be a better approach perhaps.
2010-02-03 14:13:26 utc anb_ or improving ruote-kit with what I need... I can live with fsstorage
2010-02-03 14:13:39 utc tosch_le yes.
2010-02-03 14:14:51 utc tosch_le and embedding ruote into ruby apps running in a multithreaded env is a breeze now, too.
2010-02-03 14:15:02 utc anb_ anywhere I can find an overview of the REST interface of ruote-kit ? besides looking at the code ?
2010-02-03 14:15:22 utc anb_ but unfortunately, the rest of our app is in django, we'll have to interface through http
2010-02-03 14:15:25 utc tosch_le i was just about to answer: look at the code...
2010-02-03 14:15:30 utc anb_ ;)
2010-02-03 14:15:59 utc tosch_le in that case rk is truely your friend
2010-02-03 14:16:34 utc tosch_le ruote-kit-client sheds some light on the REST interface, too, but it's also code-only.
2010-02-03 14:17:16 utc anb_ and I'm kind of new to ruby, but it's getting clearer
2010-02-03 14:17:40 utc anb_ I'll have a look to the rk client, thanks
2010-02-03 14:17:59 utc anb_ I should write one for python
2010-02-03 14:18:18 utc tosch_le (i hope rk's interface hasn't changed since the last update to rk-client but don't suppose so)
2010-02-03 14:19:44 utc tosch_le i'm no coding two years in ruby and it's more fun every day.
2010-02-03 14:19:56 utc tosch_le s/no/now/
2010-02-03 14:20:49 utc tosch_le had a look at python, but not too deep. the workload, alas.
2010-02-03 14:21:54 utc tosch_le one hint to rk's interface: you'll only have to look at the three files in lib/resources
2010-02-03 14:22:12 utc tosch_le the methods are really self-explanatory.
2010-02-03 14:23:27 utc tosch_le note that rk registers a "catch all participant" by default which uses the StorageParticipant implementation. you have to change that behaviour if you want to add other (non-storing) participants.
2010-02-03 14:27:30 utc anb_ good point, I was going to ask about participants
2010-02-03 14:28:09 utc anb_ and I must say I'm a bit confused about the StorageParticipant but I should be able to find what it does in the docs
2010-02-03 14:31:25 utc tosch_le the storage participant is a good way for asynchronous workflow steps -- human interaction in most cases. it consumes a workitem and put's it into the storage. you may retrieve the workitems stored (all of them, by field value or by a participant name) and update them. when the workitem is processed (human interaction done for example), you reply and to the engine and the flow continues.
2010-02-03 14:32:23 utc tosch_le in opposite, most other participants consume a workitem, process it and reply immediately to the engine.
2010-02-03 14:33:42 utc anb_ great. this is exactly what I am looking for ! users will get a list of "tasks" in the django web app and it will resume the flow when it's done
2010-02-03 14:34:31 utc tosch_le yeah, when talking about task lists, the storage participant is you're friend.
2010-02-03 14:34:52 utc tosch_le s/you're/your/ ahh. my english sucks :-(
2010-02-03 14:35:31 utc anb_ mine isn't better
2010-02-03 14:36:36 utc tosch_le the storage participant is best for human interaction. when you have some automated tasks to do, other participants will probably be a better choice.
2010-02-03 14:37:03 utc tosch_le there's ruote-jig for http callbacks and even ruote-amqp...
2010-02-03 14:37:06 utc anb_ all right. at first I thought about using a queue, like rabbitmq for the user tasks but it's overkill, isn't it ?
2010-02-03 14:38:00 utc tosch_le if the tasks are directed at humans: yes, i suppose so. but i have any experience with rabbitmq and co so it's hard for me to consider
2010-02-03 14:42:08 utc anb_ great Torsten, thanks a lot for your time
2010-02-03 14:42:15 utc tosch_le never mind.