Balazs Lengyel wrote:
Hello,
I vote for MUST NOT. Why complicate things. Will it bring us anything?
Things are complicated either way.
First, what are the choices?
1) require interleaving MUST be supported by the agent
2) allow interleaving to be supported by the agent,
but just warn that the manager SHOULD NOT interleave
and the agent MAY NOT accept interleaved requests.
3) allow interleaving to be supported by the agent,
based on the '#interleave' capability,
and also warn that the manager SHOULD NOT interleave
and the agent MAY NOT accept interleaved requests.
4) require interleaving MUST NOT be supported by the agent
- what happens when the manager sends an <rpc> anyway?
a) close session
b) ignore request
c) send operation-failed response
What are the benefits?
There obvious benefit from allowing interleaving,
if you believe sessions are expensive -- it saves an extra session
on both the manager and the agent.
The real benefit is that <close-session> is a the cleanest way
to terminate sessions, and it should be used in all modes.
The <kill-session> and drop connection methods are both bad ideas.
It would also be a HUGE CLR to forbid interleaving completely.
In the future, some new feature will come up that will make it
clear the agent should never be in a mode it MUST stop listening
to all input from the client. It will be clear then (if not now)
that this is a really bad idea.
So what are the benefits of forbidding interleaving completely,
and what happens if the manager sends an <rpc> anyway?
I submitted the same comment as Dave in trac, but it seems that there
is no email about updates to trac issues.
Balazs
Andy