[zeromq-dev] what happens to the bindings with libzmq libzapi ...

[Pieter Hintjens]

On Mon, Apr 25, 2011 at 10:35 PM, Brian Granger <ellisonbg at gmail.com> wrote:

> For a project written in C++, that C++ API, should be *the* C++ API
> and the C API should be a thin layer on top of that.  If those APIs
> are broken or confusing, let's just fix them in 3.0.

Yes, that would be obvious, but afaik you can't layer C on top of C++.

> I haven't followed the development closely enough, but I just buy
> this.  Groups have developed software that is much more complex that
> zeromq with C/C++ APIs and not had any difficulty or needed to develop
> additional APIs.  What exactly is not scalable?

Afaics, we face a problem of growth, and to some extent, breaking off
pieces so they can develop independently is part of the answer. The
C++ API has stagnated, as part of the core. There was no high-level C
API at all, though it's clearly necessary (C apps need reactors, smart
message classes, etc. too).

For language bindings, if we follow the above plan, there will be two
libraries to wrap: libzmq (core) and libzutil (utilities). That's all.
We should be able to make this transparent to most users by providing
a libzmq-bundle (e.g. the ZeroMQ-2.x package) that provides both APIs
in one library. To be honest I'd expect more libraries to appear over
time, libzhttp, libzsasl, etc.

It would in theory be possible to put the libzapi C code into libzmq,
but that would be more confusing. Libzapi is not meant to be wrapped
by other language bindings, whereas the libzmq C API is.

Regarding libzutil split off libzmq, it's not how I'd do things, my
tendency would be to grow libzmq over time. However I can't argue with
Martin's ambition of making the API smaller, simpler, and closer to
POSIX over time.

-Pieter