[zeromq-dev] conventions in bindings

[MinRK]

On Thu, Feb 2, 2012 at 02:52, john skaller <skaller at 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
> skaller at users.sourceforge.net
>
>
>
>
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20120202/64e8f01a/attachment.htm>