Re: Open-top coordinators and protocol

[Mark Little <mcl@arjuna.com>]

> Just in case this has been missed in what we have been saying: I am in
> favour of piggybacking messages where possible. However, I do not believe
> that we should come up with a protocol that mandates it or requires it
> because such optimisations may not be possible, or may get in the way of,
> for example, debugging (one of your examples requiring the disabling of
> interposition). I would have thought that we could come up with a protocol
> specification that could address this.
>
> For example, in the OTS when using interposition it is entirely legal to
> delay registration of the subordinate coordinator until the response of
the
> actual application message flows back, simply because the context flows
back
> on the response as well. If we do not preclude reverse context
propagation,
> then such optimisations may actually be more natural.

And as a further follow-on, surely a specification that said something along
the lines of (and I significantly paraphrase!): "actors send their messages
to other actors, and if such messages can be piggybacked to save bandwidth
and improve performance then fine; since this happens at the message level
it should be transparent to the actors." Then if you want to use
interceptors at either end of a protocol-pipe sobeit, and if you don't
that's fine too; importantly we don't say how this happens, leaving it up to
vendors. The actors who sit on top of these pipes don't see the intelligence
that they possess (assuming they do multiplexing/demultiplexing), and the
protocol remains easy to understand. The drawback is in terms of
interoperability, where sender and receiver must have the same intelligence
(does not have to be implemented in the same way though).

Mark.

-----------------------------------------------------------------------
SENDER : Dr. Mark Little, Architect (Transactions), HP Arjuna Labs
PHONE  : +44 191 222 8066, FAX : +44 191 222 8232
EMAIL  : mark@arjuna.com