notify( ) vs call( )

[Mark Taylor]

On Tue, 6 May 2008, Alasdair Allan wrote:

> So, in a PLASTIC'y sort of way I have a client that wants to tell all the 
> listening clients to image.display and then image.panTo.sky.
>
> However it doesn't really care if they do it or not... does it really have to 
> callAll( ) clients, or can it just notifyAll( ) clients instead...
>
> ...what are the rules the say this MType is a call( ) and this one is a 
> notify( )? From reading the specification its implied, but not really 
> explicitly stated, that *.event.* MTypes are notify()'able and others are 
> call()'able.
>
> Is that the intention... or is the more flexibility intended here?

No it is not the intention - at least it's not mine, and although we had
considerable debate and some confusion around this issue in the last 
few weeks I believe it's not the intention of the other authors.
Mike - [I'm sure you will] shout if you disagree with my clarifications 
below.

Any MType may be delivered either using call*() or using notify*() methods.
The delivery method (call or notify, which just determines whether
a response is required and returned) is a completely separate question 
to the message semantics (which are defined by the MType).
It is true that in practice some MTypes will more usefully be delivered
using notify and others will more usefully be delivered using call,
but there is no compulsion - it is entirely up to the sending application 
whether it wants to wait for and see the responses from the recipients
or whether it doesn't care.

So in your example above, you can just call notifyAll() and forget
about it.

> Either way I think this needs to be made more explicit in the specification.

Evidently it does.  I propose revising section 2.5 as follows:

    \subsection{Sending and Receiving messages}
    \label{sect:delivery-outline}

    Messages can be sent according to three patterns, differing in
    how and whether a response is returned to the sender:
    \begin{enumerate}
            \item Notification
            \item Asynchronous Call/Response
            \item Synchronous Call/Response
    \end{enumerate}
    The Notification pattern is strictly one-way while in the Call/Response
    patterns the recipient returns a response to the sender.

    If the sender expects to receive some useful data as a result of the
    receiver's processing, and/or if it wishes to find out whether and
    when the processing is completed, it should use one of the Call/Response
    variants.  If on the other hand the sender has no interest in what
    the recipient does with the message once it has been sent, it
    may use the Notification pattern.  Notification, since it involves
    no communication back from the recipient to the sender, uses
    fewer resources.
    Although typically ``event''-type messages will be sent using Notify
    and ``request-for-information''-type messages will be sent using
    Call/Response, the choice of which delivery pattern to use is
    entirely distinct from the content of the message, and is up to
    the sender; any message (MType) may be sent using any of the above
    patterns.
    Apart from the fact of returning or not returning a response,
    the recipient should process messages in exactly the same way
    regardless of which pattern is used.

    From the receiver's point of view there are only two cases,
    Notification and Asynchronous Call/Response.
    However the hub provides a convenience
    method which simulates a synchronous call from the sender's point of view.
    The purpose of this is to simplify the use of the protocol
    in such situations as scripting environments which cannot easily handle
    asynchronicity.  However, it is recommended to use the asynchronous pattern
    where possible due to its greater robustness.

and also adding the following to the end of section 3.9:

    Note that the two different cases from the receiver's point of view,
    Notification and Call/Response, differ only in whether a response is
    returned to the hub.  In other respects the receiver should treat
    the message in exactly the same way for both patterns.

Al - would that have made it clearer (or did the confusion arise from
text elsewhere)?  Thomas and Mike - any objections?

Mark

-- 
Mark Taylor   Astronomical Programmer   Physics, Bristol University, UK
m.b.taylor at bris.ac.uk +44-117-928-8776 http://www.star.bris.ac.uk/~mbt/