ruote log_2010-06-22

2010-06-22 07:34:42 utc lbt morning
2010-06-22 07:34:59 utc tosch_le good morning!
2010-06-22 07:35:25 utc jmettraux morning !
2010-06-22 07:36:02 utc lbt just got your mail jmettraux
2010-06-22 07:36:53 utc lbt looking at the spec side
2010-06-22 07:37:49 utc lbt I was wondering if we should bring the amqp client in from daemon-kit
2010-06-22 07:38:38 utc lbt it's kinda tricky having them out of lockstep ... and makes testing harder ... and makes it more likely that users will have issues
2010-06-22 07:38:44 utc jmettraux I wonder what is the logic for having it in daemon-kit, I wish we could discuss that with Kenneth
2010-06-22 07:39:00 utc lbt probably simple evolution :)
2010-06-22 07:41:37 utc kennethkalmer hey guys
2010-06-22 07:41:45 utc kennethkalmer just on the phone quickly
2010-06-22 07:41:47 utc lbt nb ... dropping the "command" was on the cards... but right now it means I can't have "delete_user" as a process step and need "remote_system :command => '/user/delete'" ..... ugh :(
2010-06-22 07:41:54 utc lbt oh hi kennethkalmer :)
2010-06-22 07:42:24 utc lbt we're hacking on amqp stuff ... would be good to chat on direction at some point :)
2010-06-22 07:42:41 utc kennethkalmer now is a good time :)
2010-06-22 07:42:46 utc jmettraux if you read carefully my email, you'll see that you still can have "delete_user" as a participant
2010-06-22 07:42:51 utc kennethkalmer need a break from the chaos that is my office
2010-06-22 07:43:04 utc lbt jmettraux:
2010-06-22 07:43:13 utc lbt ACTION needs more coffee
2010-06-22 07:43:28 utc lbt kennethkalmer: have you seen the recent activity on r-a ?
2010-06-22 07:43:30 utc kennethkalmer ACTION emits espresso dopio's for #ruote
2010-06-22 07:43:36 utc lbt ACTION grabs 2
2010-06-22 07:43:39 utc jmettraux thanks !
2010-06-22 07:43:51 utc kennethkalmer let me catchup over a smoke
2010-06-22 07:43:55 utc tosch_le ACTION grabs one, too
2010-06-22 07:43:56 utc lbt ACTION emits chocolate wafer biscuits...
2010-06-22 07:44:12 utc kennethkalmer awesome, love wafers
2010-06-22 07:44:16 utc tosch_le ACTION munches chocolate wafer biscuits
2010-06-22 07:44:55 utc kennethkalmer our office internet is almost non-existent, please pardon my lag while trying to read mail
2010-06-22 07:45:19 utc lbt np... I'll write a bit and expect some lag
2010-06-22 07:46:00 utc lbt so looking at the amqp I'd like to pull all the ruote logic into ruoute-amqp and have d-k simply able to include that and some templating
2010-06-22 07:46:53 utc lbt it would allow easier integration into non-dk servers and would also mean d-k and r-a don't need to be upgraded in lockstep
2010-06-22 07:47:53 utc lbt thinks like adding a 'cancel' message would be easier to handle too
2010-06-22 07:49:28 utc lbt ah jmettraux, sorry, you've added participant_options as a namespace inside params ... gotcha
2010-06-22 07:50:43 utc jmettraux if you want me to shorten it to "options", it should be OK
2010-06-22 07:51:30 utc lbt the main thing is to keep the pdef and register syntax as sweet as possible
2010-06-22 07:51:43 utc jmettraux indeed
2010-06-22 07:52:41 utc kennethkalmer epic gmail fail
2010-06-22 07:52:47 utc lbt heh
2010-06-22 07:52:55 utc kennethkalmer office internet :/
2010-06-22 07:52:57 utc lbt cyrus 4ever
2010-06-22 07:53:24 utc kennethkalmer k, on the extraction of amqp from dk
2010-06-22 07:53:29 utc kennethkalmer i think it is a good idea
2010-06-22 07:54:03 utc kennethkalmer one thing that does bother me is the dependency r-a has on r
2010-06-22 07:54:11 utc jmettraux ?
2010-06-22 07:54:28 utc lbt on the remote side
2010-06-22 07:54:32 utc kennethkalmer yeah
2010-06-22 07:54:40 utc lbt *nod*
2010-06-22 07:55:07 utc jmettraux it can limit itself to hashes and arrays
2010-06-22 07:55:43 utc kennethkalmer so, how do we do it ? do we make a r-a-remote gem ?
2010-06-22 07:56:09 utc kennethkalmer which is super light
2010-06-22 07:56:12 utc lbt gem packaging :) not my area
2010-06-22 07:56:22 utc jmettraux well
2010-06-22 07:56:23 utc kennethkalmer jmettraux: wdyt ?
2010-06-22 07:56:35 utc lbt conceptually could we do ruoute-common
2010-06-22 07:56:43 utc jmettraux the more I think about it... I'd do nothing except provide guidelines
2010-06-22 07:56:45 utc lbt which has no dependencies?
2010-06-22 07:57:01 utc jmettraux since those guidelines would be the same for java, python, ruby, ...
2010-06-22 07:57:17 utc kennethkalmer ah
2010-06-22 07:57:21 utc kennethkalmer i have an idea
2010-06-22 07:57:22 utc lbt ruote-common contains ruote data definitions ... and would express the API ... making it easy for other languages to copy
2010-06-22 07:57:50 utc kennethkalmer ruote-amqp-remote, which is a practical ruby gem and also serves as a reference implementation for other languages
2010-06-22 07:58:11 utc jmettraux ruote-workitem maybe
2010-06-22 07:58:26 utc lbt jmettraux: yes...
2010-06-22 07:58:36 utc lbt although that kinda limits what goes in there
2010-06-22 07:58:40 utc lbt it may be enough
2010-06-22 07:59:11 utc lbt but you may want some expression definition to allow external launch too
2010-06-22 07:59:15 utc jmettraux http://groups.google.com/group/openwferu-users/msg/e4742619fc5cc210 in "over the AMQP fence", I use nothing no ruote code
2010-06-22 07:59:46 utc lbt true
2010-06-22 07:59:47 utc jmettraux I use no ruote code
2010-06-22 08:00:13 utc jmettraux loose coupling ftw
2010-06-22 08:00:18 utc lbt indeed
2010-06-22 08:00:49 utc lbt I like ruote-workitem as a statement of the API
2010-06-22 08:01:04 utc lbt eg now it has params.participant_options
2010-06-22 08:01:17 utc lbt where's that documented as part of the loose coupling?
2010-06-22 08:01:30 utc jmettraux "guidelines"
2010-06-22 08:01:38 utc lbt you say potato
2010-06-22 08:01:56 utc lbt that's what ruote-workitem would be ... no?
2010-06-22 08:02:07 utc jmettraux "reference implementation"
2010-06-22 08:02:28 utc lbt optional gem to provide shortcuts
2010-06-22 08:02:57 utc lbt concrete place to document shared data structures
2010-06-22 08:03:08 utc lbt no more "hmm, where do I find that?"
2010-06-22 08:03:09 utc lbt :)
2010-06-22 08:03:36 utc jmettraux I'll think about it
2010-06-22 08:03:42 utc lbt call it ruote-guidelines :)
2010-06-22 08:04:38 utc lbt OK... explain the command thing to me... I can't do:
2010-06-22 08:04:39 utc lbt engine.register_participant( :delete_user, RuoteAMQP::Participant, :queue => 'user_manager', :command => '/user/delete' )
2010-06-22 08:04:49 utc lbt AFAICS ?
2010-06-22 08:05:00 utc jmettraux why can't you do it ?
2010-06-22 08:05:38 utc lbt ACTION looking at local gitk... 60348ff62c764821cbd71f58276fcd8658657ee3
2010-06-22 08:06:53 utc jmettraux http://groups.google.com/group/openwferu-users/msg/e4742619fc5cc210 grep for "engine side"
2010-06-22 08:13:05 utc lbt OK.. so command could still be found in params ... but it also sometimes appears in participant_options.command
2010-06-22 08:13:07 utc lbt hmmm
2010-06-22 08:13:26 utc jmettraux no
2010-06-22 08:13:41 utc lbt command = params['command'] || params['participant_options']['command']
2010-06-22 08:13:55 utc jmettraux that's it
2010-06-22 08:14:06 utc jmettraux process definition > participant option
2010-06-22 08:14:08 utc lbt that's what I said?
2010-06-22 08:14:40 utc jmettraux vaguely
2010-06-22 08:14:43 utc jmettraux ;)
2010-06-22 08:15:17 utc lbt I guess it makes the participant responsible for knowing about options and every command has to be looked for in both params and p_o
2010-06-22 08:15:48 utc jmettraux it depends on your implementation
2010-06-22 08:15:51 utc lbt why?
2010-06-22 08:16:03 utc jmettraux the information is passed over the fence
2010-06-22 08:16:26 utc jmettraux the engine proposes, the participant disposes
2010-06-22 08:17:01 utc jmettraux what is wrong with that ?
2010-06-22 08:17:18 utc jmettraux you can specify parameters or options
2010-06-22 08:17:23 utc lbt OK ... I read : engine.register_participant(.... options) as being options for the engine to communicate to the participant
2010-06-22 08:17:35 utc jmettraux they are participant instantiation options
2010-06-22 08:17:59 utc jmettraux the engine doesn't know it "communicates" with participants
2010-06-22 08:18:00 utc lbt so it says "add a :command => xxx" to each use of this ...
2010-06-22 08:18:14 utc lbt you say "pass these options with each use of this"
2010-06-22 08:18:22 utc lbt which is fine
2010-06-22 08:18:36 utc jmettraux that's ruote-amqp's turf
2010-06-22 08:18:39 utc lbt just a different interpretation
2010-06-22 08:18:52 utc jmettraux ok
2010-06-22 08:19:19 utc lbt well, it means the options in register_p() are to be passed to the participant...
2010-06-22 08:19:37 utc lbt even though they share the same name, syntax, meaning as those used in the pdef
2010-06-22 08:19:48 utc jmettraux they are the instantiation options
2010-06-22 08:19:56 utc lbt eg engine.register_participant :run_command, RuoteAMQP::Participant, :forget => true
2010-06-22 08:19:57 utc jmettraux in the pdef, they are not options
2010-06-22 08:20:07 utc jmettraux they are attributes (of expressions)
2010-06-22 08:20:20 utc lbt that forget=>true is *not* the same as a forget=>true in a pdef ?
2010-06-22 08:20:29 utc jmettraux not really
2010-06-22 08:20:30 utc lbt and that's OK... so long as we're clear
2010-06-22 08:20:32 utc jmettraux but we play on it
2010-06-22 08:21:57 utc lbt OK ... so d-k ruote needs to do: command = params['command'] || params['participant_options']['command']
2010-06-22 08:22:21 utc jmettraux ok
2010-06-22 08:22:28 utc jmettraux I have to go
2010-06-22 08:22:30 utc jmettraux enjoy !
2010-06-22 08:22:36 utc lbt cheers ... l8r
2010-06-22 08:23:43 utc kennethkalmer lbt: i'll work on getting your patches and this in for the long overdue 0.1.8 dk release
2010-06-22 08:24:00 utc lbt thanks kennethkalmer
2010-06-22 08:24:02 utc kennethkalmer john has a good point with the over-the-fence stuff
2010-06-22 08:24:18 utc kennethkalmer if you don't want to use dk, implementing your own code is simple enough
2010-06-22 08:24:28 utc kennethkalmer however, the documentation lacks
2010-06-22 08:24:30 utc lbt sure ... it's important to know what's being thrown over though
2010-06-22 08:24:31 utc lbt yes
2010-06-22 08:24:39 utc kennethkalmer maybe we can buff up the ruote-amqp docs
2010-06-22 08:24:44 utc lbt and I think having an api gem would help
2010-06-22 08:24:56 utc lbt yes
2010-06-22 08:25:12 utc lbt have you read my overview?
2010-06-22 08:25:13 utc kennethkalmer if we do that (api-gem), then i'll make dk depend on it rather than duplicate effort
2010-06-22 08:25:22 utc kennethkalmer url please
2010-06-22 08:25:24 utc kennethkalmer oh
2010-06-22 08:25:25 utc kennethkalmer in the wiki
2010-06-22 08:25:29 utc lbt yes
2010-06-22 08:25:30 utc kennethkalmer let me re-read it
2010-06-22 08:25:53 utc lbt np... just keep an eye on it :)
2010-06-22 08:26:16 utc lbt and I need to understand how the rest of the docs get to the web too
2010-06-22 08:26:39 utc lbt a python ruote client is on my todo this week btw
2010-06-22 08:27:11 utc lbt and I'd like the r-a remote to be able to launch processes too
2010-06-22 08:27:18 utc lbt bbiam
2010-06-22 08:40:24 utc lbt participant_options... is that a good name?
2010-06-22 08:41:04 utc lbt they are in some sense default or initial values ... or values set at initialisation
2010-06-22 08:47:22 utc lbt kennethkalmer: ... on the "if you don't want to use dk, implementing your own code is simple enough" comment... when we start to have :forget and we need a thread to listen for cancel() messages it will get more complex to do that.
2010-06-22 08:57:13 utc kennethkalmer good point
2010-06-22 08:57:22 utc kennethkalmer so a reference gem is definitely worth it
2010-06-22 08:57:27 utc lbt *nod*
2010-06-22 08:57:54 utc lbt also... "if message = ( workitem.fields['message'] || workitem.fields['params']['message'] )"
2010-06-22 08:58:07 utc lbt I don't think we should look inside fields?
2010-06-22 08:58:45 utc kennethkalmer not too sure honestly, need to review all the patches and get a working flow on my side to see
2010-06-22 08:58:46 utc lbt that's a perfectly valid thing for a participant to use without expecting odd side effects
2010-06-22 08:59:08 utc lbt ... I'm wondering if fields should have a namespace thing going on somehow?
2010-06-22 08:59:39 utc lbt so you can safely write to anything in your namespace and 'publish' well known information there...
2010-06-22 09:00:06 utc kennethkalmer fields are just hashes that you populate with what your application requires
2010-06-22 09:00:20 utc kennethkalmer the beauty is the simplicity
2010-06-22 09:01:15 utc lbt yes.... and they'd stay that way... but by convention write to field->step_name->name = value
2010-06-22 09:01:35 utc lbt in the same way we have fields->params and fields->participant_options
2010-06-22 09:02:17 utc lbt the risk is that if I bring in a new participant and it scribbles over a name that's in use...
2010-06-22 09:03:18 utc lbt eg for a pdef a-b-c-d-e-f .... a and d may write to fields->date
2010-06-22 09:03:42 utc lbt but b and f may also write to fields->date
2010-06-22 09:04:14 utc kennethkalmer i'm following, and wondering if that isn't still application specific
2010-06-22 09:04:17 utc lbt each process step needs to know *every* field written to by every current and future step
2010-06-22 09:04:32 utc kennethkalmer you could use the participant name as a key in fields ?
2010-06-22 09:05:19 utc lbt maybe ... or the class?
2010-06-22 09:05:28 utc lbt not sure of the answer yet ;)
2010-06-22 09:05:43 utc lbt thinking about adding in, say, a notification process step
2010-06-22 09:05:59 utc lbt or writing something to update a bugzilla
2010-06-22 09:06:13 utc lbt which may be shared as a gem even?
2010-06-22 09:06:52 utc kennethkalmer that would be cool
2010-06-22 09:06:56 utc lbt name as a key makes sense... and maybe the options step or something else to do config
2010-06-22 09:07:02 utc lbt yes, I'm planning both of those
2010-06-22 09:07:30 utc kennethkalmer coffee ?
2010-06-22 09:07:34 utc lbt we will only close bugs based on a [#bugref] in a commit log in accepted....
2010-06-22 09:07:38 utc lbt yes... cheers ;)
2010-06-22 09:28:01 utc lbt hmmm 'forget'
2010-06-22 09:28:55 utc lbt that's a common engine thing.... I'm thinking it should arrive at a participant in 'params'
2010-06-22 09:29:05 utc lbt command is different... that's a d-k thing
2010-06-22 09:36:43 utc kennethkalmer command is very much a dk thing
2010-06-22 09:38:41 utc lbt just wondering what r-a is supposed to do... I can't do wi.params['participant_options']
2010-06-22 09:39:02 utc lbt so I'm thinking of copying much of workitem.rb into ruote_workitem.rb
2010-06-22 09:39:39 utc lbt also trying to figure out what code sits in the remote r-a... it shouldn't know it's remote
2010-06-22 09:39:56 utc lbt but most participants don't know about :forget....
2010-06-22 09:40:28 utc lbt but *if they do* they'd look in params ... and not have to do the spooky params['command'] || params['participant_options']['command']
2010-06-22 09:41:18 utc lbt I wonder if for the well known attributes http://ruote.rubyforge.org/common_attributes.html
2010-06-22 09:41:30 utc lbt they should be put into params by the engine
2010-06-22 09:45:57 utc lbt mmm yummy : http://gist.github.com/448259 .... not
2010-06-22 09:46:05 utc kennethkalmer timeout is in the fields, as __timeout__ (iirc), but I get your point
2010-06-22 09:46:46 utc lbt forget makes its way into params as a matter of course
2010-06-22 09:46:56 utc lbt if it is set in the pdef
2010-06-22 09:47:21 utc lbt __timeout__ is interesting as it cascades...
2010-06-22 09:47:31 utc lbt forget... hmm
2010-06-22 09:47:50 utc lbt a forget on a sequence doesn't imply a forget on each step
2010-06-22 09:49:14 utc lbt similarly I wonder what __timeout__ means/should be for the 3rd step in a 2d timed-out sequence that has taken 1.5d to get to step 3...
2010-06-22 09:49:56 utc kennethkalmer good points
2010-06-22 09:49:56 utc kennethkalmer have you discussed this with john ?
2010-06-22 09:50:03 utc lbt no... just musing...
2010-06-22 09:50:17 utc lbt it's to do with the api I think
2010-06-22 09:50:24 utc lbt the workitem *is* the api
2010-06-22 09:50:51 utc lbt and methods like forgotten() may be appropriate
2010-06-22 09:51:20 utc lbt and it may make us think about thinks like timeout_at() returning a UTC timestamp
2010-06-22 11:33:32 utc jmettraux lbt: your commit http://github.com/lbt/ruote-amqp/commit/1ae324c661ca8608ac8ace7b3eb140079f20d5e6 is unnecessary
2010-06-22 11:33:45 utc lbt it is?
2010-06-22 11:33:53 utc jmettraux http://github.com/jmettraux/ruote-amqp/blob/ruote2.1/spec/participant_spec.rb#L164
2010-06-22 11:34:43 utc lbt and @engine.register_participant( :amqp, RuoteAMQP::Participant, forget => true )
2010-06-22 11:35:13 utc jmettraux params['participant_options'] covers that case
2010-06-22 11:35:39 utc lbt I'm not liking participant_options :D
2010-06-22 11:36:04 utc jmettraux it's elegant IMO
2010-06-22 11:36:11 utc lbt http://gist.github.com/448364
2010-06-22 11:37:10 utc lbt essentially I'm thinking that when options is used to set a 'default' for a param. the data should be sent in the param
2010-06-22 11:37:13 utc lbt OTOH
2010-06-22 11:37:36 utc jmettraux params = workitem['fields']['params']; params[key] || params['participant_options'][key]
2010-06-22 11:37:37 utc lbt if something is not param related then it should go in participant options only
2010-06-22 11:38:31 utc jmettraux the params hash is cleaned by the participant expression when the workitem comes back
2010-06-22 11:38:50 utc lbt nevertheless.. the other point is that RuoteAMQP::Participant isn't a participant
2010-06-22 11:39:06 utc jmettraux What is it then ?
2010-06-22 11:39:06 utc lbt it's a proxy of some kind
2010-06-22 11:39:13 utc jmettraux ok
2010-06-22 11:39:16 utc lbt the other end is/should be a participant
2010-06-22 11:39:26 utc lbt and it should not need to know that it was called via r-a
2010-06-22 11:39:50 utc lbt if a non-r-a participant is expected to look in p_options then that's OK
2010-06-22 11:40:03 utc jmettraux it is expected
2010-06-22 11:40:06 utc jmettraux well
2010-06-22 11:40:19 utc jmettraux there is a variant, I can compact the values and pass them all in params
2010-06-22 11:40:34 utc jmettraux ie do the x || y for you in the RuoteAMQP::Participant
2010-06-22 11:40:38 utc lbt I was thinking of passing common_params in params
2010-06-22 11:40:41 utc lbt yes
2010-06-22 11:41:00 utc lbt but that means that a 'workitem' is always parsed in the same way
2010-06-22 11:41:18 utc lbt ie you look in params for the info you need
2010-06-22 11:41:31 utc jmettraux what about the other fields ?
2010-06-22 11:41:38 utc lbt I'm just making suggestions here BTW...
2010-06-22 11:41:45 utc jmettraux you know you receive a workitem
2010-06-22 11:42:13 utc lbt *nod*
2010-06-22 11:42:40 utc lbt what other fields?
2010-06-22 11:49:06 utc jmettraux the rest of the workitem fields, the payload
2010-06-22 11:49:18 utc jmettraux workitem.fields['customer_name'] ...
2010-06-22 11:49:49 utc lbt well, actually I was discussing that with kennethkalmer earlier... just musing on it
2010-06-22 11:50:26 utc lbt http://gist.github.com/448373
2010-06-22 11:51:08 utc lbt actually, I edited it to include earlier comments
2010-06-22 11:52:39 utc lbt honestly I'm just wondering what a participant should expect and/or be guaranteed to find in a workitem
2010-06-22 11:53:33 utc lbt and whether we should have workitem.forgotten? defined as the api ?
2010-06-22 11:54:04 utc lbt In a remote participant it may actually have to jump through hoops to determine the answer.
2010-06-22 11:55:07 utc lbt don't get me wrong... when I looked at participant_options as an instance-local set of defaults then I like it :)
2010-06-22 11:55:12 utc jmettraux you're complicating things
2010-06-22 11:55:16 utc lbt yeah, maybe
2010-06-22 11:55:41 utc lbt but params = workitem['fields']['params']; params[key] || params['participant_options'][key] is complec
2010-06-22 11:56:18 utc lbt and it crashes if you move code in a r-a participant to a local participant
2010-06-22 11:56:25 utc jmettraux a) I pass that b) I compile the params, but the remote participant cannot make decision based on params or options, only decisions on params compiled
2010-06-22 11:56:35 utc jmettraux it will crash anyway
2010-06-22 11:57:02 utc jmettraux sincerely, I hate having params in the process definitions
2010-06-22 11:57:03 utc lbt I just meant that ['participant_options'] is only present in r-a
2010-06-22 11:57:12 utc jmettraux but I understand the benefits of it
2010-06-22 11:57:25 utc lbt *nod*
2010-06-22 11:57:28 utc jmettraux I shut up and I try to provide a solution that covers all the needds
2010-06-22 11:57:29 utc jmettraux needs
2010-06-22 11:57:47 utc lbt I too want to minimise the use
2010-06-22 11:57:53 utc jmettraux I could pass param_options to all the participants
2010-06-22 11:57:55 utc jmettraux it's easy
2010-06-22 11:58:03 utc lbt a param seems like an mechanism to handle exceptional situations
2010-06-22 11:58:09 utc jmettraux just a two line change and some tests to write
2010-06-22 11:58:15 utc lbt but.... :)
2010-06-22 11:58:43 utc lbt then it becomes a tad ugly that every bit of code needs to do the check against params and p_options
2010-06-22 11:58:46 utc jmettraux somehow you don't have the complete view
2010-06-22 11:58:47 utc lbt IMHO
2010-06-22 11:59:03 utc lbt oh, if you tell me to go read the code I'm happy
2010-06-22 11:59:06 utc jmettraux you could have a helper method and then it's solved
2010-06-22 11:59:12 utc lbt I *know* I'm new at this :)
2010-06-22 11:59:16 utc jmettraux I didn't tell go read code
2010-06-22 11:59:20 utc lbt heh
2010-06-22 11:59:33 utc jmettraux I'm trying to explain to you that my opinion is not restricted to r-a
2010-06-22 11:59:40 utc jmettraux I have to keep a watch on the whole
2010-06-22 11:59:46 utc lbt OK.... listening
2010-06-22 12:00:27 utc lbt I'm trying to think of how r-a can be as non-special as possible
2010-06-22 12:00:48 utc jmettraux I understand that
2010-06-22 12:00:53 utc lbt :)
2010-06-22 12:01:09 utc jmettraux but please understand that some decisions are deeper roots than you may think
2010-06-22 12:01:24 utc lbt I do
2010-06-22 12:01:48 utc lbt when I'm making commits to ~lbt I'm just sharing ideas... not expecting them to be accepted
2010-06-22 12:02:17 utc jmettraux ok, understood
2010-06-22 12:04:08 utc lbt question... should all participants take :forget=>true as options in the register()
2010-06-22 12:04:20 utc jmettraux no
2010-06-22 12:04:55 utc lbt that only came about because r-a had that historically as that reply_anyway
2010-06-22 12:05:11 utc lbt I renamed it to forget for consistency
2010-06-22 12:05:15 utc lbt maybe it should just go?
2010-06-22 12:05:28 utc jmettraux I could accomodate it just fine
2010-06-22 12:05:42 utc jmettraux a night or two of reflection
2010-06-22 12:05:45 utc jmettraux reflexion
2010-06-22 12:05:54 utc lbt reflection
2010-06-22 12:07:35 utc jmettraux thanks
2010-06-22 12:08:18 utc jmettraux I think I should drop the participant_options
2010-06-22 12:08:34 utc jmettraux there could be "sensitive" info in there
2010-06-22 12:09:34 utc lbt well...
2010-06-22 12:09:57 utc lbt I liked the concept of the old 'map()' thing
2010-06-22 12:10:08 utc lbt and p_options is like that...
2010-06-22 12:10:50 utc lbt it's pretty essential for r-a.... and better than special-casing queue and command
2010-06-22 12:11:24 utc lbt the thing is ... is it for the participant class or the code using the class
2010-06-22 12:12:02 utc lbt queue is for the proxy side - the r-a user code never cares...
2010-06-22 12:12:15 utc lbt command is for user code (the d-k implementation)
2010-06-22 12:12:53 utc lbt forget is kinda for the local engine and an optimisation for the r-a class to not reply to the ruote_workitems queue
2010-06-22 12:16:37 utc jmettraux the map thing was not adapted to ruote 2.1.z
2010-06-22 12:16:55 utc lbt no, it totally didn't make sense... the p_options replaces it nicely
2010-06-22 13:05:20 utc lbt FYI http://github.com/lbt/daemon-kit/commits/master/
2010-06-22 13:06:13 utc jmettraux line 191 to 194 could be replaced with 1 line
2010-06-22 13:06:29 utc jmettraux ( http://github.com/lbt/daemon-kit/commit/e90d85c251c9a41550ba5ed727f14b1101245210 )
2010-06-22 13:07:52 utc lbt OK ... I was kinda blundering around some ruby learning issues and it got to that
2010-06-22 13:08:24 utc jmettraux ok
2010-06-22 13:08:40 utc lbt the if params and was because I was treating the workitem as a hash when it was a class
2010-06-22 13:09:08 utc lbt the d-k workitem class isn't the same API as the ruote one :(
2010-06-22 13:09:26 utc jmettraux so I shouldn't feel guilty for "ugly" code :)
2010-06-22 13:09:41 utc lbt heh
2010-06-22 13:09:50 utc lbt most of the code here is really easy to grok
2010-06-22 13:10:00 utc lbt a few places the overloading catches me out
2010-06-22 13:15:12 utc jmettraux I plead non guilty for line 191 to 194, this is not my fault
2010-06-22 13:16:19 utc lbt no, not at all :)
2010-06-22 13:16:57 utc lbt what kenneth wants to do is get a 'client' into r-a
2010-06-22 13:17:27 utc lbt it will need to handle things like forget not passing back workitems
2010-06-22 13:17:45 utc lbt and it'll need a thread/queue to listen for cancel
2010-06-22 13:19:30 utc lbt I'd also like it if you take code written to subclass Ruote:LocalParticipant and essentially change the class to Ruote:AMQPParticipant then 'it just works'
2010-06-22 13:20:01 utc lbt OK ... gotta go... back l8r
2010-06-22 13:20:11 utc jmettraux ttyl
2010-06-22 13:43:09 utc kennethkalmer jmettraux: http://docs.google.com/gview?url=http://mens.de/:/couchdbref
2010-06-22 13:43:39 utc jmettraux kennethkalmer: hello
2010-06-22 13:43:42 utc jmettraux cheatsheet ?
2010-06-22 13:43:47 utc kennethkalmer yep
2010-06-22 13:43:54 utc jmettraux many thanks !
2010-06-22 13:44:12 utc kennethkalmer pleasure
2010-06-22 16:33:46 utc lbt well, I can launch ruote process from python now :)