I have asked a number
of technical and scenario based questions about Doug’s proposal as well.
I merely responded to Doug’s rather open reading of the charter to
understand how IBM thought that a general purpose polling mechanism was in
scope.
Given how tight this
proposal is tied to RM to solve these problems I don’t have the same
concerns here anymore, this is clearly not a general purpose polling mechanism.
I did initially have those concerns about Paul’s earlier proposal as
well.
I also continue to
have problems with your server-> anonymous client scenario. Paul has already
quite correctly pointed out you couldn’t do this with the contributed
spec either. It certainly doesn’t seem to have been a problem anyone was
concerned about until very recently. Even now it seems rather academic, the
scenario where this is important has not been explained in my mind. IBM seems
to be using more than anything else as a justification to add poling to RM. You
could use the line of logic you guys are promoting here on this anywhere else,
although I guess you have already conceded that point.
As IBM is proposing
we solve this with this general purpose polling function you guys favor it requires
an unreliable request and a reliable response. Isn’t this exactly the
thing IBM argued was not important during the discussions of operation vs.
endpoint level reliability? I can only surmise you like this now because it
supports your polling proposal which again, seems to have very little to do
with RM.
From: Christopher B Ferris
[mailto:chrisfer@us.ibm.com]
Sent: Thursday, May 04, 2006 3:36
AM
To: wsrx
Subject: RE: [ws-rx] Minimalist
GetMessage proposal
We've been over this many times. Any RMS should be free to make its own
determination as to when
IT
requests creation of a Sequence. The RMS at the server side of an RMD that can
only be accessed via
the
anonymous endpoint is/should be no exception. Further, your CS/Offer doesn't
work for use cases
where
reliability is only in the server->client direction because there would not
be a Sequence for the
client->server
direction.
I am
curious though as to why you seem to have no problems with discussing the
technical merits
of
this proposal, when with Doug's, you are simply asserting that the discussion
is out of scope.
Cheers,
Christopher
Ferris
STSM, Software Group Standards Strategy
email: chrisfer@us.ibm.com
blog: http://www.ibm.com/developerworks/blogs/dw_blog.jspa?blog=440
phone: +1 508 377 9295
"Marc
Goodner" <mgoodner@microsoft.com> wrote on 05/03/2006 11:51:51 PM:
> I agree this proposal is a lot tighter in
scope.
>
> I'm not to convinced of the need to poll for
a CS so that doesn't
> trouble me very much. Your suggestion for the
addition of Offer is an
> interesting idea. I'm not sure how much it
really optimizes things when
> the client instead of polling for an inbound
CS could simply start with
> an outbound CS with an Offer for an inbound
sequence. The outbound
> sequence would be independent of the inbound
one so it could be
> terminated before the inbound one if it was
not needed.
>
> Marc Goodner
> Technical Diplomat
> Microsoft Corporation
> Tel: (425) 703-1903
> Blog: http://spaces.msn.com/mrgoodner/
>
>
> -----Original Message-----
> From: Durand, Jacques R. [mailto:JDurand@us.fujitsu.com]
> Sent: Wednesday, May 03, 2006 7:24 PM
> To: Paul Fremantle; wsrx
> Subject: RE: [ws-rx] Minimalist GetMessage
proposal
>
> I must say the proposal is much improved and
scoped.
> It of course works only with offered
sequences - I am still trying to
> convince myself that not being able to poll
for CS is not a (serious)
> issue.
> A wild idea: the unreliable-in/reliable-out
case could be handled better
> by allowing an wsrm:Offer on the
GetMessage...
>
> Jacques
>
> -----Original Message-----
> From: Paul Fremantle [mailto:paul@wso2.com]
> Sent: Wednesday, May 03, 2006 12:05 PM
> To: wsrx
> Subject: [ws-rx] Minimalist GetMessage
proposal
>
> Based on some of the discussions it seemed to
me that it could be
> valuable to produce a completely
"minimalist" GetMessage proposal.
>
> This is a new proposal that is based on the
previous WSO2 proposal.
>
> The proposal removes the MessageID selector
in the GetMessage - relying
> on simply getting whatever message the server
sends back next.
>
> Also it removes the section 4.2. Effectively
section 4.2 is an
> optimisation: for example to support
unreliable-in/reliable-out a client
>
> could do a createsequence+offer and never use
the outgoing sequence. In
> this case there is an overhead, which 4.2
aimed to remove, but this
> simplifies the proposal by focussing on the
bare minimum required to
> support the most common use cases, but still
allowing the other use case
>
> with a slight overhead.
>
> I've also included a sample message flow
which I hope helps understand
> the proposal and show the general usage.
>
> Paul
>
> --
>
> Paul Fremantle
> VP/Technology, WSO2 and OASIS WS-RX TC
Co-chair
>
> http://feeds.feedburner.com/bloglines/pzf
> paul@wso2.com
>
> "Oxygenating the Web Service
Platform", www.wso2.com
>