W3C home > Mailing lists > Public > xml-dist-app@w3.org > February 2006

Follow-ups to today's call: 2 (timing and the trickiness thereof)

From: David Hull <dmh@tibco.com>
Date: Wed, 08 Feb 2006 17:30:19 -0500
To: "xml-dist-app@w3.org" <xml-dist-app@w3.org>
Message-id: <43EA70FB.5050400@tibco.com>
I agree with Noah that a major difference (I think Noah would say /the/
major difference) between the flavors of request-response and true fire
and forget is to do with timing.  You can generally do either over the
other (actually you can't: see /below/), but you may get nasty surprises
when, say, the callback that's waiting for a response to your FAF
request hangs around longer than you want.

Unfortunately, trying to define things like "longer than you want" or
"long-running operation" is tricky.  To some people microseconds may be
a long time.  Others may not mind waiting for minutes or hours.

The way out, I believe, is just to talk about what steps you have to go
through in each situation.  In request-response, receiving a response --
and thus waiting for it -- is part of the contract (modulo failure).  In
FAF, it isn't.  Or more accurately, in cases where you still do have to
wait for something, it's pushed into a different operation.  It's not
part of the contract for the FAF MEP.

I'm afraid this is either tautological or completely obscure (or both).

/Below/: Multicast pub/sub protocols are inherently FAF.  If I try to
layer request-response on top of such a protocol using WSA, I will get
any number of responses (including zero) depending on who's listening to
the multicast.
Received on Wednesday, 8 February 2006 22:30:32 UTC

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