notify( ) vs call( )

[Alasdair Allan]

Mark Taylor wrote:
> However, since Al has already misunderstood what we've written,  
> perhaps I'm being over-optimistic about the potential for confusion.

Maybe we're just being over-optimistic about how smart I am...

> ... 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).

sendNotify[All]()
sendAsynch[All]()
sendSynch[All]()

recieveNotify[All]()
recieveAsynch[All]()

Maybe? Nothing wrong with the word "Notify" it conveys the right  
meaning.

> 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

I'd be happy with this...

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

I'd be happy with trhis...

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

Yuck! I'd argue against this (if I have to)...

>    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

Yuck! I'd argue (heavily) against this (if I have to)...

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

Happy enough with this...

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

Probably the same order here (although I really don't like 3 and 4).  
I don't think there is anything wrong with the current scheme, I just  
think it needs more explanatory text. The linking between the  
different calls and the MType vocabulary in the draft is too weak.  
Just need a few sentences (under an obviously titled section heading)  
to explain whats going on. A fundamental rethink of the way the calls  
work, don't think so...

Cheers,
Al.