On Thu, Feb 2, 2012 at 02:52, john skaller <skal...@users.sourceforge.net>wrote:
> > 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 > This I think is exactly the point of confusion I would like to address. zmq_msg_t *does not* contain a message, it contains a message *fragment*. A Message is the information contained in a collection of (one or more) zmq_msg_t objects linked by SND/RCV_MORE. If zmq_msg_t is referred to as a MessageContainer, than a Message contains multiple MessageContainers, which in turn each contain a MessageBuffer. -MinRK > > 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 > skal...@users.sourceforge.net > > > > > _______________________________________________ > zeromq-dev mailing list > zeromq-dev@lists.zeromq.org > http://lists.zeromq.org/mailman/listinfo/zeromq-dev >
_______________________________________________ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
