| 2013-06-06 20:18:54 utc | jmettraux | gruntruk1: hello and welcome to #ruote |
| 2013-06-06 20:30:38 utc | gruntruk1 | jmettraux: thanks! :) first off lemme say thanks for all your contributions! ruote looks really cool! |
| 2013-06-06 20:30:55 utc | jmettraux | oh, thanks! |
| 2013-06-06 20:32:11 utc | gruntruk1 | i've been looking through the docs, reading some of the examples, etc. i'm still trying to get my head around storage participants and how they relate to "humans doing offline, potentially long running tasks". i'm prototyping using ruote to run some automated steps with a healthy sprinkling of human intervention in between |
| 2013-06-06 20:32:59 utc | gruntruk1 | barley.rb seems to be the best sample I think for what i'm trying to do |
| 2013-06-06 20:33:13 utc | jmettraux | storage participants are mostly like inboxes |
| 2013-06-06 20:34:38 utc | gruntruk1 | yeah. i think i am starting to understand. the orchestration will sit idle until i reply to the workitem in question and trigger it to move on to the next action. does that sound about right? |
| 2013-06-06 20:35:05 utc | gruntruk1 | by "trigger it to move on" I mean reply to the workitem |
| 2013-06-06 20:36:15 utc | jmettraux | yes, that's it |
| 2013-06-06 20:58:51 utc | gruntruk1 | jmettraux: in looking at https://github.com/jmettraux/ruote/blob/master/examples/barley.rb#L70 … i obtain a process identifier when launching my pdef, but when trying to fetch all workitems i seem to be getting an empty result. does the StorageParticipant in your example need to be scoped somehow if i'm registering storage participants under specific names? |
| 2013-06-06 21:00:48 utc | gruntruk1 | e.g. i'm setting mine up as follows fwiw: http://pastie.org/pastes/8016511/text?key=0sd3jjtm7baezzaf4jv5ca |
| 2013-06-06 21:03:29 utc | jmettraux | ok, you launch a flow, but no workitems do show up |
| 2013-06-06 21:03:33 utc | jmettraux | could there be an error in your flow? |
| 2013-06-06 21:03:57 utc | jmettraux | engine.process(wfid).errors == 0 ? |
| 2013-06-06 21:04:44 utc | gruntruk1 | :| apologies. i've not started the worker to actually process anything |
| 2013-06-06 21:04:47 utc | jmettraux | your snip looks alright |
| 2013-06-06 21:04:50 utc | jmettraux | ah ok |
| 2013-06-06 21:05:03 utc | jmettraux | didn't notice that :-) |
| 2013-06-06 21:05:19 utc | gruntruk1 | my mistake. i've been evolving my prototype from command line sinatra and missed that |
| 2013-06-06 21:05:30 utc | gruntruk1 | command line to sinatra i mean |
| 2013-06-06 21:05:32 utc | gruntruk1 | thanks |
| 2013-06-06 21:08:31 utc | jmettraux | no worries |
| 2013-06-06 21:26:58 utc | gruntruk1 | okay, last question for the night! re: the TaskList implementation here http://ruote.rubyforge.org/implementing_participants.html - would the local participant in this case result in a thread being run unlike storage participant? |
| 2013-06-06 21:28:48 utc | jmettraux | so yes, storage participant have "def do_not_thread; true; end" so no dispatch thread |
| 2013-06-06 21:29:26 utc | jmettraux | and this TaskList doesn't have that directive, so there would be a (short lived) dispatch thread wrapping the call to on_workitem |
| 2013-06-06 21:29:40 utc | gruntruk1 | okay… i might be able do a task list yet base it off of storage participant. that would let me have a long running operation, and drive the completion off of a bunch of open ended task list type operations from the DB |
| 2013-06-06 21:29:46 utc | jmettraux | one could safely add "def do_not_thread; true; end" to the TaskList implementation |
| 2013-06-06 21:30:15 utc | gruntruk1 | okay. thanks so much for your time and help. it's been really useful! |
| 2013-06-06 21:30:46 utc | jmettraux | you're welcome, good night! |
| 2013-06-06 21:30:56 utc | gruntruk1 | bye! |