ruote tmp/log_2013-06-06.html

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 … 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:
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 - 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!