- From: Mark Baker <distobj@acm.org>
- Date: Thu, 1 Mar 2007 16:47:49 -0500
- To: "noah_mendelsohn@us.ibm.com" <noah_mendelsohn@us.ibm.com>
- Cc: "David Orchard" <dorchard@bea.com>, www-tag@w3.org
On 3/1/07, noah_mendelsohn@us.ibm.com <noah_mendelsohn@us.ibm.com> wrote: > > Dave: I know you're collecting ideas for the finding on State in Web > application design. One aspect of this that I understand is coming up > increasingly is the legal need in many contexts for certain enterprises to > reliably record every access that is made to certain data. In such cases, > an obligation of a sort is implicit in every access, and presuming HTTP > GET in particular is inappropriate. I think this is a real world issue > for many users of Web technology. I'm thinking it might be the basis of > an interesting use case, though I'm somewhat on the fence as to whether it > fits better in the whenToUseGET space. The fact that there are side > effects of the access seems to be whenToUseGet, I don't think that's an issue. As Jacek said, safety is about incurring obligations, so it's not harmful that an implementation of GET causes side effects, it's just harmful if the message sender is blamed for those side effects. > but I imagine that in many > cases it will be important to record not just that an access has occurred, > but also information about the higher level interaction (session?) in > which the access occurs. That might bring a tie in to the state finding. That's an excellent point. If an interaction is stateful, then the meaning of the message is partly a function of information not in the message. So logging facilities should be logging not just the message, but any referenced state. Mark. -- Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca Coactus; Web-inspired integration strategies http://www.coactus.com
Received on Thursday, 1 March 2007 21:47:56 UTC