- From: Laird A Popkin <laird@io.com>
- Date: Sun, 26 Aug 2001 07:18:57 -0500 (CDT)
- To: Kurt Cagle <cagle@olywa.net>
- cc: <xml-dist-app@w3.org>
On Sat, 25 Aug 2001, Kurt Cagle wrote: > Cookies are an attempt to push the state maintenance onto the client. > Realistically, multiple transactions in a process will need to maintain a > session token, but that session token should in all truth be passed back and > forth between transactions in the SOAP message itself. A long term > subscription services makes caching a transaction id necessary at the very > least. Still I'm not sure how such cookies or handles, if passed within the > body of the SOAP message itself, would necessarily place that much of an > onus upon addressability. Since you mention subscription services in particular, I'll mention that ICE (http://www.icestandard.org) handles subscription state by giving a "state" (cookie) to the subscriber, which is transmitted in the protocol for every update request generated by the subscriber. This allows the subscriber to be responsible for its state, which (1) allows the syndicator not to have to track subscriber state, which is a good thing, and (2) allows the subscriber to manage whether he transitioned from the old state to the new state. In terms of mapping the ICE application semantics over SOAP as a transport, however, I don't think that we need SOAP to understand any of this -- it's just another piece of data in a message, particularly because ICE allows you to place transactions within multiple subscriptions into the same physical message, so the subscription-level state cannot be at the physical transport layer. I'd also encourage anyone interested in subscription/syndication and SOAP to send me some email. Thanks! - Laird Popkin, Chair, ICE Authoring Group http://www.icestandard.org laird@3path.com, laird@io.com
Received on Sunday, 26 August 2001 08:19:05 UTC