[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: New issue: Facilities to support optional MakeConnection.underspecified
The spec implies that MakeConnection is required of all
implementations. Since there appear to be preconditions to initiating polling,
and these preconditions are outside the scope of the spec, it is entirely
possible that a particular implementation can refuse to accept the
preconditions that require polling. Such a refusal is reasonable, as polling can be resource
intensive (requires a store of messages waiting to be polled). Buffering
messages has inherent limits:
Since accepting the preconditions is not mandatory,
effective use of a MakeConnection is also effectively optional. However
the negotiation of this scenario is currently outside the scope of the spec,
and is likely to suffer a loss of interoperability as a result. The optional
nature should be clarified in the spec, and further infrastructure should be
deployed (e.g. a MakeConnectionRefused error, possibly an
rm:MakeConnectionEnabled policy assertion) to assist in interoperability in
determining at run time, possibly even at design time, whether a MakeConnection
attempt has been, or will be, successful. With MakeConnection+SeqID, there is a clear marker that
Polling is being "initiated" - a
CreateSequence+Offer+WSA-AnonymousEPR indicates that two way reliability with
Anon is happening. The server can either fault CreateSeqRefused or can fail to
accept the Offered sequence (which is after all the troublemaker).
However, with MakeConnection+RManonURI, the RMAnonURI can be
"slipped" in at some earlier point into messages that do not have any
relationship to the RM agent, for example as a ReplyTo. The RM agent may not be
handling that message, but in this case what does the server do with this
message? |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]