W3C home > Mailing lists > Public > xml-dist-app@w3.org > December 2005

Re: [Fwd: Toward more fully-formed options]

From: Mark Baker <distobj@acm.org>
Date: Wed, 14 Dec 2005 16:07:37 -0500
Message-ID: <c70bc85d0512141307y5e215ef0o599a5f241373496b@mail.gmail.com>
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.


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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 22:01:28 UTC