Sunil Kunisetty wrote:
>Tom Rutt wrote:
>
>
>
>>Sunil Kunisetty wrote:
>>
>>
>>
>>>>
>>>>
>>>I don't think that restriction is warranted. What is important is the Poll
>>>request is initiated by the Sender in a different transaction/connection
>>>than the original message. How the response (Ack or Fault) is sent
>>>is an implementation issue and doesn't effect our protocol one way
>>>or other.
>>>
>>>
>>>
>>I do not understand. The justification for poll is when the sender
>>cannot accept http requests.
>>
>>
>
> While that is the primary justification, that's not the only one. For your
> recollection, other use cases are avoid resends & for thin clients.
>
> Also, that would have been the prominent one if Poll was only used for
> that scenario, and not with other patterns. However, now that we allow
> Poll to be used for Callbacks and Response patterns also, then the use
> case I suggested is much more valid.
>
>
I agree that the poll request can be used to obtain status infomation
for reliable messages sent using any reply pattern.
The point I am making is that the poll request is always (by definition
and design) mapped to an underlying request/response protocol.
Thus there is no problem distinguishing a delayed callback response
(which is always on an underlying request) from a poll response
(which is always on a underlying response).
----------------------------------------------------
Tom Rutt email: ;
Tel: +1 732 801 5744 Fax: +1 732 774 5133
