- From: Conor P. Cahill <concahill@aol.com>
- Date: Mon, 10 Oct 2005 07:46:13 -0400
- To: "Pete Hendry" <peter.hendry@capeclear.com>
- cc: public-ws-addressing@w3.org, "David Hull" <dmh@tibco.com>, "Marc Hadley" <Marc.Hadley@Sun.COM>
Pete Hendry wrote on 10/10/2005, 4:54 AM: > > I thought I'd mention that the original thrust of my misgivings > was the lack of ability for the server to pass back session > information as reference parameters for subsequent client > calls (the more useful direction in my opinion). The fact > that the endpoint address could also be changed wasn't > really something I thought of originally but is a nice > side-effect. > > One thing I was not aiming for was the concept of "from now on > when you contact me" from the server but rather that the > server/service would pass back the EPR in each response. For > the former, the client must maintain state over multiple calls > to the same service whereas I was just looking for a way to > pass an EPR in the response to one request to be used in the > next request by that client (not *all subsequent requests*). > I think the scope of these approaches is different and what > I am asking be consdered for inclusion is the simpler of the two > approaches. I think the difference between "the next request" and "subsequent requests" is simply a matter of degee and that the server should be able to control this. I'm a bit concerned about saying just "the next request" because of the possibility of multiple outstanding requests from a client to the server. What does the client do when they need to submit a second request before the server has responded to the first request in this model? In our world, we see the server applying a TTL on the use of the replacement data which may or may not coincide with a TTL elsewhere in the request (such as the TTL in a security token included in the request). Conor
Received on Monday, 10 October 2005 11:46:37 UTC