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
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
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
think we dilute the mtype
by allowing message patterns to corrupt the method names.
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
-Mike Received on 2008-05-13Z10:18:12