Hi Dan,
I think partial respones and the MakeConnection feature are very
different things:
The purpose of partial responses is to use an *existing connection* to
piggyback acks on them.
Creating a new connectionon may be a solution for acknowledging
responses received from the server in the absence of further application
request, but anonymous acksTo means that
acknowledgements should be sent over the existing HTTP connection.
Andrea.
Dan Diephouse wrote:
My point wasn't that we should use the MakeConnection from 1.1. It was
that
instead of doing partial responses we *could* invent our own proprietary
operation which is similar to MakeConnection.
On 1/11/07, Glynn, Eoghan <[EMAIL PROTECTED]> wrote:
> -----Original Message-----
> From: Dan Diephouse [mailto:[EMAIL PROTECTED]
> Sent: 10 January 2007 22:41
> To: [email protected]
> Subject: Re: Understanding Partial Responses [Re:
> Identification of Partial Responses]
>
> On 1/10/07, Glynn, Eoghan <[EMAIL PROTECTED]> wrote:
> >
> >
> > Essentially we took a view on how to plug a hole in the
> WS-RM spec. We
> > did this in a way that other RM implementors (and
> contributors to the
> > WS-RX spec) also had in mind. This approach happens to go
> against the
> > chapter and verse of the WS-I Basic Profile (R2714), but it
> has been
> > argued that BP was in error on this point.
> > *snip*
>
>
> And they ultimately decided against including such a feature
> inside the spec.
>
> http://www.oasis-open.org/committees/download.php/14147/Reliab
> leMessagingIssues.xml#i012
Again, note that the WS-RX TC decided against this approach for _1.1_.
However that was no help to _1.0_ implementors such as ourselves, who
still had to figure out a way of solving the problem within the
framework of the 1.0 spec ... and in fact in many cases had already come
to a de facto work-around before MakeConnection was even a twinkle in
the spec writers' eye.
> That doesn't necessarily mean it isn't useful though. I've
> done some more in depth poking around and it appears other
> people are doing it, so I believe it is a justified feature.
Hallelujah! :)
> Also I've done some more research into how other frameworks
> do this and have some findings, which I'll bring up in the
> original identification thread.
>
>
> >
> > I don't think it would be a good idea to support a hodge-podge of
> > WS-RM 1.0 and 1.1, for a number of reasons ... the 1.1
> namespaces are
> > all different, 1.1 is based on a different version of WS-A, and 1.1
> > removes some features we support (e.g. the LastMessage marker).
> >
> > So I think we'd be much better off waiting for 1.1 to be finalized,
> > then going for it in one fell swoop.
>
>
> Shouldn't we be able to support both versions eventually?
Sure, for reasons of backward compatability and wider interop ... just
as we currently have multi-version support for WS-A.
But my point was that we shouldn't support a hybrid version (i.e. mostly
1.0, but with MakeConnection thrown in).
So a discrete choice would be made at runtime for each RMS->RMD
interaction, either fully 1.0 or fully 1.1, but not a mixture of both.
Cheers,
Eoghan
