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}
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@bris.ac.uk +44-117-928-8776 http://www.star.bris.ac.uk/~mbt/Received on 2008-05-12Z19:03:53