| 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 http://github.com/kennethkalmer/ruote-kit/issues |
| 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. |