rationale behind 'message_name'

[Dieter Van Eessen]

Hello Maciej Sobczak,

Been playing a bit with yami. I like WHY this library abstract
messaging the way it does. The rationale speaks to me.

One thing which confused me at first is the addition of
'message_name' as a message header. In the general purpose libs
(python, c++), this message_name appears to be required when sending a
message. While at server side, its usage is optional. 
Somewhere in the docs, it states that 'message_name' models the
'action_name', or otherwise identifies the kind of processing that is
expected from the message handler. 

For me, it appears that there are 2 reasons for including 'message_name'
in the message headers:
- to keep some analogy with the concept of 'subject' in an email/internet messages.
- in an object oriented environment (using python here), the __call__
  could redirect to other methods based on 'get_message_name()' of the
  message. This clearly separates usage of meta-data from usage of
  user-payload.

I can understand there is a requirement for a concept which provides
a way to 'specify kind of processing', and that this info is
classified as meta-data, not user-payload.
But is this not actually what a user would intend to accomplish with
'object_name'? It is not the messagehandler/callable which implements 'the kind of
processing'?

Object_name is required as meta-data, since this is the essence of how
yami abstracts the receiver of a message. 
But in my opinion 'message_name' is redundant: if the user wants a different 
'kind of processing', the server should implement a different callable. 
For me, it appears this concept has only been created out of habit and
therefore only weighs on complexity without giving any additional
value.
I admit, it's a thin line I'm hanging on. But it bugs me... hence this post.

What do you think?

kind regards,
Dieter Van Eessen

[Maciej Sobczak]

Hello Dieter,

One thing which confused me at first is the addition of
'message_name' as a message header.

[...]

 

But is this not actually what a user would intend to accomplish with
'object_name'? It is not the messagehandler/callable which implements 'the kind of
processing'?

You are right that in the general-purpose library [*] there are two concepts (object name and message name) that can be used to direct the processing on the server side. These two concepts were intended to reflect and translate the object-oriented designs, where objects have methods - and where, in its pure theoretical form, methods are invoked by sending messages to objects.

So, the idea is that if you want your printer to print some document, then you send the message "print" to the object "printer". If you instead want the printer to shut down, you send the message "shutdown" to the same objec "printer" - but if you want to shut down the TV set instead, then you send the message "shutdown" to a different object, "tv" perhaps. This shows that both message names and object names can be used to differentiate the processing at the receiving side and they can be interpreted at different levels. The object name indicates who should handle the message, whereas the message name indicates the work to be done. This division is of course artificial, because you might as well achieve the same results with just a single directive, for example named "printer.print" or "printer.shutdown" or "tv.shutdown". But having two separate values instead of just one helps in some idioms like sending "shutdown" in a loop to all your known target devices - and this way of thinking is similar to how we design object-oriented systems. In the C++ analogy:

- object name is like an object pointer

- message name is like a member function pointer

That is, you need both of these values to get somebody to do something.

[*] But this is all a matter of convention. The general-purpose library is a high-level messaging library that proposes some set of programming idioms and ideas, like the one above, on top of a core library, which is more low-level and which does not impose any conventions. In the core library the message is composed of two parts: the header and the body, which can be both structured in any way. It is up to the client and the server to agree on how they interpret both parts and it is even OK to use empty headers if it is always understood what is the meaning of the message body. You might even build a more elaborate system, where the header will contain a lot more complex meta-data (example: security tokens). But the convention of using a pair of object name and message name seemed to be quite commonly understood in the software engineering world and that convention was implemented in the high-level library.

Hopefully this explains the rationale - let me know if there is anything that needs further discussion!

 

Best Regards,

--

Maciej Sobczak