[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: Re [ws-rx] i137: No mechanisms to convey that messages shouldbe polled.
Paul, I modeled this on the ackrequested/ack headers. In that case, it was not considered necessary to ack every message, but if the RMS needed an ack, it could always request it. But this case is different. The reason ack is not sent for every message is cause the ack header may be the only thing that is sent and therefore a separate message. In the polling case, the MessageStatus and MessageStatusRequested are always piggybacked. It is pointless to send a MessageStatusRequested as the only thing in the message (you might as well send a MakeConnection). It is also not possible to send the MessageStatus on it is own -- because we are talking about sending this to an RMD on a backchannel (to RMDs behind firewalls), so at the very least it is getting piggybacked on the transport backchannel message. So I agree that having just one header simplifies the proposal. -Anish -- 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]