- From: Mark Baker <distobj@acm.org>
- Date: Wed, 14 Dec 2005 16:07:37 -0500
- To: David Hull <dmh@tibco.com>
- Cc: xml-dist-app@w3.org
On 12/14/05, David Hull <dmh@tibco.com> wrote: > > > Yes, I think you've missed the possibility of the server not sending a > response within a timeframe that the client deems suitable. > > That seems like a failure to me. At least, it seems that for our present > purposes we can abstract this under the same rug as network failures, server > crashes and whatever else. If I send an HTTP request, either an HTTP > response comes back or something bad happens, and for our purposes it > doesn't much matter just what kind of bad thing happened. That could very well be, as I haven't looked at the big picture of this issue enough to know. I was just responding to that one sentence of yours. > On the other hand, if the server gets my request, doesn't like it and sends > back a fault, that's a response. The distinction is basically the > distinction between checked and unchecked exceptions (faults are checked, > failures are unchecked). In this respect, what constitutes a failure is to > some extent a matter of definition. I'm basically asserting that any result > other than an HTTP response (in a timely manner) should be treated as an > "unchecked exception". This is open to discussion, which is one reason for > trying to state the assumptions explicitly. > > That said, I'm pretty well convinced that any result other than an HTTP > response coming back should be treated as a failure. Sounds good. Cheers, Mark. -- Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca Coactus; Web-inspired integration strategies http://www.coactus.com
Received on Wednesday, 14 December 2005 21:07:59 UTC