ruote tmp/log_2012-07-20.html

2012-07-20 10:40:09 utc hartog hi
2012-07-20 10:43:53 utc jmettraux hello
2012-07-20 10:51:38 utc hartog how can I make sure that a catchall participant is always placed on the back of the list?
2012-07-20 10:52:39 utc jmettraux I'd say, make sure no other participants get added after it
2012-07-20 10:52:46 utc hartog had a funny bug this morning where, due to intensive testing and mal-use (granted), the catchall participant crept up the list - this gives funky results
2012-07-20 10:53:17 utc jmettraux using Dashboard#register with a block could help
2012-07-20 10:53:26 utc jmettraux it blanks the participant list by default
2012-07-20 10:54:29 utc hartog did it do that in 2.2.0 also?
2012-07-20 10:54:53 utc jmettraux let me check the commit log
2012-07-20 10:55:01 utc hartog might be nice to put in the docs if so
2012-07-20 10:55:22 utc hartog that is, imho, totally unexpected behavior
2012-07-20 10:55:33 utc jmettraux no, it's 2.3.0
2012-07-20 10:56:26 utc hartog on the other hand; forcing people to think about participant lists by blanking them might actually be sort of nice
2012-07-20 10:56:49 utc jmettraux well, it's actually documented: http://ruote.rubyforge.org/participants.html
2012-07-20 11:01:13 utc hartog No its not: http://rubydoc.info/github/jmettraux/ruote/Ruote/Engine#register-instance_method ;)
2012-07-20 11:02:07 utc jmettraux what do you mean?
2012-07-20 11:03:09 utc jmettraux https://github.com/jmettraux/ruote/blob/master/lib/ruote/dashboard.rb#L599-777
2012-07-20 11:04:10 utc hartog confusing
2012-07-20 11:04:25 utc jmettraux what is confusing?
2012-07-20 11:04:30 utc hartog rubydoc.info is supposed to be up-to-date
2012-07-20 11:04:43 utc hartog guess they need a pinch of ruote in their backends ;)
2012-07-20 11:04:48 utc jmettraux lol
2012-07-20 11:05:08 utc hartog ACTION stops complaining now, ok?
2012-07-20 11:31:43 utc tosch_le late reply, but the reason might be that rubydoc.info is using the latest gem to build the documentation
2012-07-20 11:32:07 utc jmettraux thanks tosch_le
2012-07-20 12:39:42 utc hartog what is the easiest way to have a particpant cancel the (rest of the) process?
2012-07-20 12:41:30 utc jmettraux for a "local" participant, it's something like @context.storage.put_msg('action' => 'cancel_process', 'wfid' => wfid)
2012-07-20 12:41:43 utc jmettraux (and not to reply)
2012-07-20 12:43:12 utc hartog thx!
2012-07-20 12:43:48 utc hartog would reply(:cancel) make any sense?
2012-07-20 12:44:26 utc jmettraux iirc the reply method expects a workitem
2012-07-20 12:44:47 utc hartog i know, but I could implement it for you :)
2012-07-20 12:45:21 utc tosch_le i'd answered @context.dashboard.cancel(wfid)
2012-07-20 12:45:30 utc jmettraux would that fit with the rest of the design?
2012-07-20 12:45:40 utc tosch_le that hides implementation details better imho
2012-07-20 12:45:41 utc jmettraux tosch_le: yes, even better
2012-07-20 12:45:44 utc jmettraux +1
2012-07-20 12:46:50 utc hartog there should be an easier, less opaque way imho
2012-07-20 12:47:44 utc hartog i would say 'reply(:cancel)' (or perhaps something as funky as 'reply(:rewind)') seem valid in the ''DSL'' of the participant
2012-07-20 12:48:52 utc jmettraux locally looks nice, globally I don't know how this would fit
2012-07-20 12:50:36 utc jmettraux the current deal is receive a workitem, give back a workitem (or don't give back anything)
2012-07-20 12:52:30 utc tosch_le why not have a #cancel method in the ReceiverMixin?
2012-07-20 12:52:59 utc hartog tosch_le: would that not interfere with the cancel method of the participant?
2012-07-20 12:53:18 utc tosch_le yes, it would
2012-07-20 12:53:24 utc tosch_le sorry
2012-07-20 12:53:32 utc jmettraux #cancel_process and #cancel_expression maybe
2012-07-20 12:54:06 utc hartog that makes sense
2012-07-20 12:54:27 utc jmettraux but wait, like you said, we already have @context.dashboard.cancel_x and _y
2012-07-20 12:54:37 utc jmettraux those shortcuts would come in handy
2012-07-20 12:54:41 utc hartog jmettraux: in the simplest shortest form; what exactly is an expression?
2012-07-20 12:55:29 utc jmettraux this flow
2012-07-20 12:55:46 utc jmettraux define { sequence { toto } }
2012-07-20 12:55:51 utc jmettraux has three expressions
2012-07-20 12:55:56 utc jmettraux define, sequence and toto
2012-07-20 12:56:04 utc jmettraux where toto is a ParticipantExpression instance
2012-07-20 12:56:29 utc hartog ACTION is getting the picture
2012-07-20 12:56:33 utc jmettraux running a flow is instantiating expressions, applying them, waiting for their replies
2012-07-20 12:59:01 utc hartog thx
2012-07-20 12:59:39 utc jmettraux cancelling is always cancelling an expression
2012-07-20 12:59:50 utc jmettraux cancelling a process is thus cancelling the root expression of a process
2012-07-20 13:01:02 utc jmettraux ruote-kit is good at showing how a process decomposes in expressions
2012-07-20 13:01:33 utc hartog it is, but i needed 3-bits more context to grasp the whole
2012-07-20 13:03:07 utc hartog and after all that; it turns out that #flunk does _exactly_ what I need
2012-07-20 13:04:21 utc hartog (almost)
2012-07-20 13:04:24 utc hartog :)
2012-07-20 13:26:44 utc hartog jmettraux: another 'quicky' - can i alter msg in the observer?
2012-07-20 13:29:11 utc jmettraux that'd make it a participant ;-)
2012-07-20 13:30:28 utc hartog for statistics gathering i'd like to inject a 'launched_at' => Time.now into the msg
2012-07-20 13:30:43 utc hartog but I dont want to rewrite all my pdefs
2012-07-20 13:30:51 utc jmettraux you could add it at launch time
2012-07-20 13:31:11 utc hartog how?
2012-07-20 13:32:04 utc jmettraux yeah right, not that easy
2012-07-20 13:32:34 utc jmettraux wait who's going to consume that info afterwards?
2012-07-20 13:32:50 utc jmettraux (I was thinking you could add the info to the workitem fields)
2012-07-20 13:32:50 utc hartog ACTION cooks a gist; hang on
2012-07-20 13:33:25 utc jmettraux another idea: https://github.com/jmettraux/ruote/blob/master/lib/ruote/dboard/process_status.rb#L346-351
2012-07-20 13:34:24 utc jmettraux observers get the msg after it got processed, when all the observers have seen the msg it gets garbage collected (hopefully)
2012-07-20 13:35:06 utc hartog https://gist.github.com/3150714
2012-07-20 13:35:13 utc hartog (was what I was hoping for)
2012-07-20 13:36:24 utc jmettraux what is going to read that info?
2012-07-20 13:36:50 utc jmettraux a msg is an action [order], it's not a context
2012-07-20 13:37:07 utc jmettraux it's like "launch that flow" or "cancel that expression"
2012-07-20 13:37:19 utc jmettraux once the action has been performed, the msg is discarded
2012-07-20 13:37:52 utc jmettraux two suggestions
2012-07-20 13:38:02 utc jmettraux a) you put the launched_at info in a workitem field
2012-07-20 13:38:15 utc jmettraux advantage, even participants know about the launch time
2012-07-20 13:38:35 utc jmettraux disadvantage, participants can tamper that info (unless you prevent them somehow)
2012-07-20 13:39:01 utc jmettraux b) since you need the info in the termin...
2012-07-20 13:39:05 utc jmettraux well there is no b
2012-07-20 13:39:22 utc jmettraux si the root expression is gone when the "terminated" msg occurs
2012-07-20 13:39:40 utc hartog could I yield a service to inject stuff into the workitem?
2012-07-20 13:39:43 utc jmettraux (msgs that have actions that are past participles are more like events)
2012-07-20 13:39:58 utc jmettraux you have control at launch time
2012-07-20 13:40:29 utc jmettraux dashboard.launch(pdef, 'launched_at' => Time.now.to_s)
2012-07-20 13:41:39 utc hartog makes sense
2012-07-20 13:42:39 utc hartog another solutions is to not log the stuff into a file, but use [#{msg['workitem']['wf_name']}] as a key to some key-value store and record statistics there
2012-07-20 13:44:20 utc jmettraux on the project I'm currently on, we have a WorkflowInstance model, with launched_at, terminated_at and co
2012-07-20 13:48:29 utc hartog care to share? ;)
2012-07-20 13:50:03 utc jmettraux sorry, proprietary
2012-07-20 13:50:08 utc hartog figures
2012-07-20 13:50:11 utc hartog :D
2012-07-20 13:50:50 utc tosch_le have to leave, bye!
2012-07-20 13:50:56 utc hartog bye!
2012-07-20 13:51:04 utc jmettraux bye!
2012-07-20 13:51:06 utc hartog have a nice weekend!
2012-07-20 14:03:04 utc jmettraux hartog: I have to leave as well, enjoy the weekend!