[zeromq-dev] multi-part messages

[Martin Lucina]

skaller at users.sourceforge.net said:
> I see no technical reason that you cannot *add* an array based interface:
> two extra functions.

Sure, there is no technical reason, but it's a question of demand and
(more importantly) API maintenance.

Regarding demand, if enough people see the benefit in an array-based
sendmmsg() / recvmmsg() interface, then such an interface can be added.

Regarding API maintenance, we have the same problem as the Linux kernel;
once an API is added, it will be used by applications, hence that API will
have to stick around "for ever" (but see below).

> Having done that you could deprecate the old interface.
> 
> In 4.x you can remove it from the core API. It can still be supported
> by a "legacy" API. After all the "legacy" API would simply populate
> the array and the call send function (and the reverse for recv).

That's how it works in theory. In practice once you have a sizeable amount
of users, you have to keep such legacy APIs around for a long time -
deprecation becomes a slow process.

Anyhow, in this particular case, IMHO, the sendmmsg () / recvmmsg () APIs
can coexist nicely with the existing APIs and we *don't* want to deprecate
ZMQ_MORE since it's the only way to write devices which can handle
multi-part messages in a generic fashionb with the current model.

> Just as a matter of curiosity .. "how much"  0MQ use is from C?
> C++? Other languages? [The question means: is the C API 
> primarily for application programming, or it there primarily
> to support bindings to better languages?]

That's kind of like asking "how many people still program in C". A lot :-)

The libzmq C API serves 4 purposes:

a) a lowest common denominator baseline
b) the API that language binding developers use
c) for those application programmers who are familiar with the POSIX APIs
and do not need/want anything more abstract
d) for those application programmers that need the performance and control
of using it directly from C

IMHO one of the reasons ZeroMQ is so successful is precisely because we
decided early on to stick with a POSIX-like C API. There are a lot of
developers out there who have some degree of familiarity with these APIs,
so it makes the barriers to adoption (how quickly can I get "something"
working) very low.

-mato