[zeromq-dev] conventions in bindings

[john skaller]

On 02/02/2012, at 12:19 PM, Gary Wright wrote:
> 
> 
> message: 
>  the PDU sent between ZMQ endpoints consisting of one or more fragments
>  The total length of a message (# of fragments *or* # of bytes) is
>  not encoded in the message itself by ZMQ.
> 
> fragment:
>  A length delimitated blob and a flag indicating if the fragment
>  is the last fragment of a message or not. The API (libzmq) is
>  designed around sending and receiving fragments (vs. entire messages).
> 
> frame:
>  the 'wire' format for a ZMQ fragment, not directly visible via
>  the API, used to delimit fragments on various byte oriented
>  transports.


This sits well with my understanding and terminology, but it leaves two terms
of import unspecified:

message-bufffer:
a char array of finite and possibly zero length which may be
used to hold a fragment and may be associated with a
a zmq_msg_t object and/or may be used directly
as the argument of a send/recv function

message-container: 
a zmq_msg_t object

IMHO: every C programmer has a good concept of 
what a buffer is, so I doubt that is controversial.

The term is important wrt zmq_msg_t objects in
particular considering ownership and lifetime
issues.

Really, the biggest problem is that zmq_msg_t object is called
a message.

Technically even Gary's definition of message is a perversion of language:
the actual message is the interpretation of the byte sequence,
i.e. a message has *semantic content*. This proper interpretation actually
has semantic impact: it is possible that the machinary to construct in memory,
transmit, and receive elsewhere, the message *representation* may 
fail to transmit the actual message: it may become garbled, or,
at a higher level than ZMQ fail to be coded/decoded correctly,
or it may arrive in the wrong order wrt other messages.  This is
(hopefully) not zmq's concern but is intended to illustrate the distinction
between message representation (data) and message (information).

Recall Mashal MacLuhan: "The medium is the message".

I have one further input here: if there were a small team which would
rewrite the API specification to improve precision and consistency ..
and historically, Standards bodies that do this sometimes **deliberately**
change away from existing practice to avoid confusion, I suggest
such term should research existing POSIX terminology.

It would also be good to copy the description model used by the
Open Group:

http://pubs.opengroup.org/onlinepubs/007904975/mindex.html
http://pubs.opengroup.org/onlinepubs/007904975/functions/send.html

and I would note that this already seems to be the goal. Note in this
selected example:

"""
The send() function shall initiate transmission of a message 
from the specified socket to its peer. 
The send() function shall send a message only when the socket is 
connected (including when the peer of a connectionless socket has been set via connect()).

buffer
Points to the buffer containing the message to send.
"""

an existing use of the word "message". ZMQ should be constrained to use
the same meaning if appropriate, and not use the term at all otherwise.

--
john skaller
skaller at users.sourceforge.net