[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]