ruote tmp/log_2012-11-14.html

2012-11-14 02:26:00 utc lmarburger jmettraux: i had the opportunity to play with ruote some more today. do you have a minute for me to pick your brain about how i'm approaching this problem? i'm still not quite clear on "the ruote way"
2012-11-14 02:53:59 utc lmarburger heh. great comment for ParticipantRegistrationProxy#method_missing: # Maybe a bit audacious...
2012-11-14 02:59:48 utc jmettraux lmarburger: hello, I'm back
2012-11-14 03:00:38 utc lmarburger hey, jmettraux
2012-11-14 03:01:26 utc lmarburger so here's what i'm playing with:
2012-11-14 03:02:36 utc jmettraux the second process never reaches "never gets here" ?
2012-11-14 03:03:18 utc lmarburger correct. in the lower process i'm showing that if either the arthur or ford respond to this incident, some external program will stop the process completely.
2012-11-14 03:03:59 utc lmarburger i think that's easier to accomplish using Dashboard#cancel or the like
2012-11-14 03:04:21 utc jmettraux so the concurrence never terminates?
2012-11-14 03:04:34 utc lmarburger in that example yes
2012-11-14 03:05:16 utc lmarburger the first may be more preferred in that if one of them respond it breaks the concurrence and continues on
2012-11-14 03:05:17 utc jmettraux there is also
2012-11-14 03:06:16 utc lmarburger wow nice. that cancels the entire process, right? not just one of the subprocesses
2012-11-14 03:06:25 utc jmettraux yes
2012-11-14 03:08:57 utc lmarburger heh i guess i didn't read the first line on that page: Cancels a whole process instance.
2012-11-14 03:09:48 utc jmettraux no worries :-)
2012-11-14 03:12:10 utc lmarburger does my usage of im and email participants make sense in that case? something doesn't feel right to me because they never reply back to the engine.
2012-11-14 03:12:35 utc jmettraux ah, yes, that might be an issue
2012-11-14 03:13:00 utc jmettraux but you can do "im forget: true"
2012-11-14 03:13:21 utc jmettraux well...
2012-11-14 03:13:24 utc lmarburger the way i have them constructed, their #on_workitem methods send the message and then some other process (to be built) will be responsible for killing a process a at a human's command
2012-11-14 03:13:49 utc jmettraux I'd say it's better if they reply
2012-11-14 03:13:51 utc lmarburger the reason it's not replying is because i want it to send an im and wait for a minute before sending an email
2012-11-14 03:14:08 utc jmettraux im; wait '1m'; email
2012-11-14 03:14:15 utc lmarburger wow
2012-11-14 03:14:23 utc lmarburger that was pretty simple
2012-11-14 03:14:41 utc jmettraux but they'd have to reply
2012-11-14 03:14:44 utc lmarburger yeah
2012-11-14 03:15:55 utc lmarburger then does it still make sense that when a human replies to one of these alerts that the system will cancel the process or is there a way to define that in ruote that i'm not seeing?
2012-11-14 03:16:34 utc lmarburger like "contact arthur and ford. when one of them replies, start this other process."
2012-11-14 03:16:43 utc jmettraux if the human is a "process administrator", he gets the chance to cancel the process manually (engine.cancel(wfid))
2012-11-14 03:16:54 utc jmettraux but yes, you could implement that
2012-11-14 03:17:26 utc jmettraux you'd need to implement a "receiver", one that polls some IMAP/POP3 thing for the answer and determines what to do
2012-11-14 03:17:54 utc lmarburger one of these?
2012-11-14 03:18:09 utc jmettraux no, not really, this is a listen expression
2012-11-14 03:18:40 utc lmarburger oh i see. lib/ruote/receiver/base
2012-11-14 03:18:52 utc jmettraux ACTION looks for some suitable doc
2012-11-14 03:19:41 utc lmarburger # A convenience methods for advanced users (like Oleg).
2012-11-14 03:19:44 utc lmarburger haha
2012-11-14 03:19:59 utc jmettraux here is an example implementation (subscribed to an AMQP queue)
2012-11-14 03:20:12 utc lmarburger there's a pretty ridiculous amount of commenting in this codebase. that's quite nice :)
2012-11-14 03:20:12 utc jmettraux ok, have to go, lunch, I'll be back in a while
2012-11-14 03:20:26 utc lmarburger thanks for your help again, jmettraux. this sounds like exactly what i want.
2012-11-14 03:20:41 utc jmettraux yeah, I try to take the time to comment
2012-11-14 03:20:45 utc jmettraux you're welcome, ttyl!
2012-11-14 12:26:42 utc MCamou hi everyone
2012-11-14 12:28:39 utc jmettraux MCamou: hello Mario
2012-11-14 12:37:37 utc jmettraux have a good day!
2012-11-14 22:59:12 utc jmettraux just documented (a little bit) the on_error extended syntax: