[Standards-JIG] stanza delivery ordering

[Tony Finch]

On Fri, 11 Aug 2006, Chris Mullins wrote:
>
> Yup. That's true. A message may have to wait for an s2s connection to be
> established, or even timeout and fail, before being processed. The same
> message may have to wait for a database to log the message, or for a xml
> signature to be verified, or for encryption to be performed, or
> cluster-failover to happen, or any of a number of items.
>
> On the other hand, it guarantees the user will get exactly the results
> that, from a "It just works the way I expect it to" perspective, he's
> expecting to get. I think this is very important.

I would have thought it strange (or at least shoddy programming) that
delays in one window would cause delays in a separate window.

> There are a number of situations we could all envision that involve
> 3-way (or more) conversations, presence priority changes, message
> routing, and responses to messages coming back, that get really strange
> if you don't do it this way.

They're likely to be strange in any case if you have that much going on at
the same time.

> The other option I can see is creating processing order rules:

I think you're making this much more complicated than it needs to be. The
current rule effectively means: route each stanza from a given source in
the order it is received from that source, and then put them on the
appropriate destination queues. Input from different sources can be
handled in parallel with no ordering constraints. Destination queues are
handled in order within a queue, and different destinations can be handled
in parallel with no ordering constraints.

This would mean that I could still carry on a conversation with PSA while
my server was trying to establish a connection to your server to deliver a
message I sent you some moments ago, because your destination queue is
independent of PSA's.

Tony.
-- 
f.a.n.finch  <dot at dotat.at>  http://dotat.at/
FISHER: WEST OR NORTHWEST 4 OR 5 BECOMING VARIABLE 3 OR 4. FAIR. MODERATE OR
GOOD.