On 5/4/06, Sanjiva Weerawarana <[EMAIL PROTECTED]> wrote:
currently <send/> new SynapseMessage and set the response msg and inject to the env for further processing. if to do prior we would have to change it. Now once <send/> done we have the new response msg. Are we continuing the rest of the ruleset with the new msg ?.
So we may expect more than one <send/> per ruleset per msg. ? if so that's pretty cool.
How does Synapse know the the end o f the ruleset per given msg?
We currently have the semantic that <send/> implicitly is an end of
execution of the current ruleset. I'd like to propose we change that:
First of all, the name is not intuitive of that behavior. OK so we can
fix the name, but I'd like to separate the two actions: that of sending
a message and that of finishing execution.
What I suggest is we change <send/> to be just that: send the message
per the semantics of send. When send is done, if there are any other
rules around they keep executing.
currently <send/> new SynapseMessage and set the response msg and inject to the env for further processing. if to do prior we would have to change it. Now once <send/> done we have the new response msg. Are we continuing the rest of the ruleset with the new msg ?.
Now, I don't want to force everyone to write <send/> either (which is
what we have now and that's cool). So how about saying that if the
ruleset completes without the message being sent, then there's an
implied <send/> at the end .. that means things work exactly as the way
it does now for when <send/> is NOT there, but if its there then one can
continue and send it to another place for example.
Note that this also has the nice feature that you can use it to send the
message, then change some stuff and send it elsewhere or send an event
somewhere or whatever.
So we may expect more than one <send/> per ruleset per msg. ? if so that's pretty cool.
How does Synapse know the the end o f the ruleset per given msg?
Thoughts?
Sanjiva.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
