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:
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@bris.ac.uk +44-117-928-8776 http://www.star.bris.ac.uk/~mbt/Received on 2008-05-13Z13:06:45