OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ws-rx message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [ws-rx] Re [ws-rx] i137: No mechanisms to convey that messagesshould be polled.


Is this yet-another i119 (EPR comparisons overly restrictive) and "when 
to piggy-back" situation?  Now that we have something in the 
specification, "targeted at the sequence" seems narrow.

On 20/06/06 03:02, Paul Fremantle wrote:
> Oh no! 2 mistakes.
> 1) forgot to update with the issue number and
> 2) <wsrm:MessagePending/>  forgot a /!
> Paul
>
> Paul Fremantle wrote:
>> Anish
>>
>> I like the idea. However, can I propose a simplification.
>>
>> I suggest that we simply allow an RMS to add a header
>>
>> <wsrm:MessagePending>
>>
>> to any message targeted at the sequence to indicate there is a 
>> message that could be polled for. I propose this should be optional 
>> (even if there is a message pending), but recommended.
>>
>> Paul
>>
>>
>>
>>
>> Anish Karmarkar wrote:
>>> Title: Polling mechanism does not provide a way for the RMS to let 
>>> the RMD know that there are pending messages that should be polled.
>>>
>>> Description/justification:
>>>
>>> We have a polling mechanism that allows messages to be polled. This 
>>> is quite helpful for RMDs that are behind the firewall. But there is 
>>> no mechanism for the RMS to let the RMD know that there are messages 
>>> that the RMD should poll for. I.e., unless the RMD polls for a 
>>> message, it will not know whether it should have polled!
>>>
>>> Having a mechanism for the RMS to let the RMD know that there are 
>>> pending messages is helpful in at least two scenarios:
>>>
>>> 1) RMD just polled for a message (perhaps because it periodically 
>>> does that), and would like to know if it should poll again because 
>>> there are additional pending messages. The RMD wants to minimize 
>>> message delivery delays, but the only way to do that is to increase 
>>> the polling period, which can result in unnecessary 
>>> sending/receiving/processing of messages. Given that the RMD has 
>>> already polled for a message, it is extremely convenient (with a 
>>> minimal cost) to allow the RMS to inform the RMD that there are 
>>> additional message waiting.
>>>
>>> 2) The RMD and RMS have ongoing communication (not necessarily a 
>>> wsrm:MakeConnection), it is advantageous for the RMD to let the RMS 
>>> know that there are pending messages by allowing the pending status 
>>> to be piggy-backed on ongoing communication messages.
>>>
>>> Core: core
>>>
>>> Type: design
>>>
>>> Proposal:
>>>
>>> Outline of the proposal --
>>> Allow two new headers wsrm:MessageStatusRequested and 
>>> wsrm:MessageStatus, which can be piggybacked on other messages, that 
>>> query and convey that there are pending messages.
>>>
>>> <wsrm:MessageStatusRequested  ...>
>>>   [<wsrm:Identifier> xs:anyURI </wsrm:Identifier>]?
>>>   [<wsrm:Address> xs:anyURI </wsrm:Address>]?
>>>   ...
>>> </wsrm:MessageStatusRequested>
>>>
>>> <wsrm:MessageStatus pending="xs:boolean" ...>
>>>   [<wsrm:Identifier> xs:anyURI </wsrm:Identifier>]?
>>>   [<wsrm:Address> xs:anyURI </wsrm:Address>]?
>>>   ...
>>> </wsrm:MessageStatus>
>>>
>>>
>>> -Anish
>>
>>
>
>


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]