| 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: https://gist.github.com/df2389d31759a1e64827 |
| 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 http://ruote.rubyforge.org/exp/cancel_process.html |
| 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 x@example.com 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? http://ruote.rubyforge.org/exp/listen.html |
| 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 https://github.com/kennethkalmer/ruote-amqp/blob/master/lib/ruote/amqp/receiver.rb (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: http://ruote.rubyforge.org/common_attributes.html#on_error_composing |