[zeromq-dev] conventions in bindings

[Martin Lucina]

skaller at users.sourceforge.net said:
> [Good definitions of
> message/fragment/frame/message-buffer/message-container snipped]
>
> Really, the biggest problem is that zmq_msg_t object is called
> a message.

The use of "message" comes from the term "message-oriented-middleware" and
"message queue", both of which can be used to describe ZeroMQ to some
extent.

> [semantic meaning of "message" snipped]

> 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:

Speaking as the original author of the ZeroMQ manual pages / API reference,
the POSIX/opengroup texts were a direct inspiration for me when I was
writing the ZeroMQ API manual. Thanks for noticing :-)

I agree that the terms "message" and "message part" are used
interchangeably in the current documentation, and that this is confusing.
Multi-part messages were introduced while I was already writing the API
documentation, and thus their documentation is a "patch" onto the original
terminology, rather than a proper rethink of terminology.

The API documentation is in need of some work as it stands today and I
would certainly like to improve this; an off-the-top-of-my-hat estimate is
that it needs a couple of man-weeks of concentrated time to address these
issues.

John, I would be very interested in working with you on this, however right
now I'm on the tail end of a fairly large project for a client, so the
earliest I can make time for this is mid-March.

Another thing I would like to improve is the code examples in the API
reference, both by improving the "snippets" of code in the individual
reference pages for API calls, and by writing a new zmq_tutorial(7) page
consisting of a series of worked examples; one per messaging pattern, using
the libzmq C API, and being enough to get "something working".

-mato