- From: David Hull <dmh@tibco.com>
- Date: Wed, 14 Dec 2005 15:49:27 -0500
- To: Mark Baker <distobj@acm.org>
- Cc: xml-dist-app@w3.org
- Message-id: <43A08557.3000905@tibco.com>
> >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. 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. >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 20:50:30 UTC