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. |