gistfile1.txt

[10:04] <lbt> also... "if message = ( workitem.fields['message'] || workitem.fields['params']['message'] )"
[10:04] <lbt> I don't think we should look inside fields?
[10:05] <kennethkalmer> not too sure honestly, need to review all the patches and get a working flow on my side to see
[10:05] <lbt> that's a perfectly valid thing for a participant to use without expecting odd side effects
[10:05] <lbt> ... I'm wondering if fields should have a namespace thing going on somehow?
[10:06] <lbt> so you can safely write to anything in your namespace and 'publish' well known information there...
[10:06] <kennethkalmer> fields are just hashes that you populate with what your application requires
[10:06] <kennethkalmer> the beauty is the simplicity
[10:07] <lbt> yes.... and they'd stay that way... but by convention write to field->step_name->name = value
[10:07] <lbt> in the same way we have fields->params and fields->participant_options
[10:08] <lbt> the risk is that if I bring in a new participant and it scribbles over a name that's in use...
[10:09] <lbt> eg for a pdef a-b-c-d-e-f ....   a and d may write to fields->date
[10:10] <lbt> but b and f may also write to fields->date
[10:10] <kennethkalmer> i'm following, and wondering if that isn't still application specific
[10:10] <lbt> each process step needs to know *every* field written to by every current and future step
[10:10] <kennethkalmer> you could use the participant name as a key in fields ?
[10:11] <lbt> maybe ... or the class?
[10:11] <lbt> not sure of the answer yet ;)
[10:12] <lbt> thinking about adding in, say, a notification process step
[10:12] <lbt> or writing something to update a bugzilla
[10:12] <lbt> which may be shared as a gem even?
[10:13] <kennethkalmer> that would be cool
[10:13] <lbt> name as a key makes sense... and maybe the options step or something else to do config
[10:13] <lbt> yes, I'm planning both of those