notify( ) vs call( )

[Mark Taylor]

On Tue, 13 May 2008, Mike Fitzpatrick wrote:

> On Mon, May 12, 2008 at 10:03 AM, Mark Taylor <m.b.taylor at bristol.ac.uk> wrote:
>
>> 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.
>
>    Mark is well-aware, and I think agrees with the idea, that the
> current method
> names need some attention:  The doc discusses the concept of a Notification,
> Request and Reply as distinct "message types"  that correspond to certain

Although earlier (unpubliciised) versions of the document did do this, 
in the current version I don't think that's the case.  I've tried to 
separate the vocabularies:

    Call/Response  -  message delivery pattern indicating that a
                      response is required
    Notification   -  message delivery pattern indicating that no
                      response is required

    Event          -  message (MType) with semantics indicating
                      "something has happened"
    Request        -  message (MType) with semantics indicating
                      "I want you to do this"

Reply a.k.a. Response is not currently an MType semantic label, since a 
Message goes from the Sender to the Recipient and contains an MType, while
a Response goes in the other direction and does not have an MType of
its own (its semantics are defined by the fact that it is the response
to the MType of the initial Message).  I know that Mike has argued
against that, but as I've explained in an earlier message
(http://www.ivoa.net/forum/apps-samp/0805/0045.htm)
I believe that using an MType in both directions would make it 
much harder to write application code.  I would welcome other people's
opionions on that issue (responses to the message cited above).

> message patterns.  As long as notify()/call() map easily to Notification/Request
> message types things are fine, but when you use the
> Notification/notify() to send
> a Request message because you don't care about the reply, I think we're mixing
> message types and message patterns, or at least the vocabulary used to describe
> them.
>    One way around this is to send() a message and move the idea of whether you
> want a response elsewhere (e.g. in the method signature, or in the
> envelope of the
> message which started the issue of a msg Envelope/Body concept) so it

Distinguishing the two things by method signature is a promising idea,
but it does rely on the ability to overload method names, which 
is not such a good idea for an abstract interface since it may not
fit well with some implementations (e.g. toolkit libraries in 
languages which do not permit overloading).

Providing this information in a message 'envelope' is also a possibility.
At one extreme we could replace all the asynchronous call/notify hub 
methods with just

    send(map message-envelope-and-body)

where the argument encodes recipient ID, message ID, and delivery pattern
information (whether a response is required) as well as the MType and 
parameters and everything else.  This would work just as well as the
way it is currently specified, but my personal feeling is that having
the delivery information provided as separate explicit arguments in the
interface, and the message semantics in a separate argument of its
own (the "message" map) makes it clearer what's going on.

> is less-tied
> to the type of message being sent.  I think it is confusing to have a
> file.event.load mtype
> sent with a call() to require a reply or a file.load as a notify()
> because you don't care about
> the result:  One mtype is clearly an 'I did this" and the other is a
> "I want you to do this",
> the reply that may say only "I got the message" doesn't help and I

I think that by keeping the vocabularies separate (Call/Notify for
delivery patterns and Event/Request for MTypes) we can write text
and define method names which are clear and keep the concepts from
interfering with each other.  For instance I don't have a problem
in Java saying that I'm "calling" a method like 
ActionListener.actionPerformed(ActionEvent event), even though it's
just sending information that an event has happened; and I don't 
see what's wrong with "notifying" another application that I want
them to load a file.

However, since Al has already misunderstood what we've written, 
perhaps I'm being over-optimistic about the potential for confusion.
So, maybe we need method names (and associated terms for delivery
patterns) which are more clearly distinguished from message semantics.
Following your suggestion to use "send" throughout, but wanting
to use different method names for different purposes, how about
making the following method name replacements:

    hub:
       notify[All]()         ->  sendVoid[All]()
       call[All]()           ->  sendAsynch[All]()
       callAndWait()         ->  sendSynch()
    client:
       receiveNotification() -> receiveVoid()
       receiveCall()         -> receiveAsynch()

not particularly elegant, but the best I can think of (other suggestions
welcomed).

>    We could delete the Notification/Request/Reply message type
> concepts from the
> doc to clear up the method name discussion, but I think these are
> fundamental ideas
> of messaging we need to preserve for later growth

As far as the message passing machinery itself goes, none of it
needs to understand the difference between these message types,
so in that sense I believe that this part could be deleted for
simplicity.  However, the concept does throw light on the MType
vocabulary, and as you suggest it may be wise to reserve these
terms and concepts for later use.

So, I'd like to solicit opinions from others on which of the above
approaches is best.  To summarise:

    1. Leave notify()/call() methods as they are;
       Event and Request are terms only used in discussion of MTypes

    2. Leave notify()/call() methods as they are;
       Remove general discussion of distinct Event/Request MType semantics
       (though *.event.* MTypes still exist)

    3. Replace notify()/call() methods by overloaded send() method;
       Event, Request, Notify and Call may be used in discussion of MTypes

    4. Replace notify()/call() methods by single send() method with
       delivery information in message envelope;
       Event, Request, Notify and Call may be used in discussion of MTypes

    5. Replace notify()/call() methods by sendVoid()/sendAsynch();
       Event, Request, Notify and Call may be used in discussion of MTypes

    6. Your idea here.

I am not implacably opposed to any of these, but my favoured options
would be (in order) 1, 2, 5.

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/