[zeromq-dev] Cleaning-up context creation API

[Pieter Hintjens]

On Wed, Feb 15, 2012 at 6:07 PM, john skaller
<skaller at users.sourceforge.net> wrote:

> which is a bit risky IMHO. The reason is: you're delaying error detection
> in the launching of the threads. That makes it impossible to return
> an error code.

True. However errors can be returned after the fact; it's the same
issue with zmq_connect.

> close() on async sockets has the same bug (I mean posix sockets not 0MQ ones).

Yes.

> On naming: the theme seems to be using an OO friendly naming scheme.

At least a sane naming hierarchy so that people don't have to remember
lots of different naming schemes. The current API is really
inconsistent in many ways and that makes it harder to learn than it
needs to be.

> So if we're going for consistency .. "init" sucks. zmq_ctx_init creates
> a ctx. but zmq_msg_init doesn't, it initialises an existing one.

Yes, this has been pointed out before :-) We can continue to improve
things but one step at a time, and keeping old names alive.

> Similarly, "term" and "close". There's a difference between closing
> an underlying resource but leaving the object in a coherent state,
> and destroying the object (which may or may not destroy the
> underlying resource: eg .. ref counted messages).

Yes.

> If you're going to make a new, consistent API, the constructor/destructor
> naming should be consistent too. So should the argument usage
> and semantics. It's not really very nice that contexts and sockets are
> opaque, copyable pointer types, whilst "messages" are structs
> containing pointers.

All welcome but it has to be done carefully, and without breaking things.

> Actually I think message should be heap allocated like everything else.
> In a well written program, you can still move the buffers around so
> you don't need a fresh message container thing for every
> new blob of data. [** Felix binding does that anyhow, it's just
> easier for the clients and malloc is fast]

Not possible if you want performance (small messages must be stack allocated).

> Finally, the options interface SUCKS for C clients. It's ok for language
> bindings other than C. If I had to use the get/set socket options much
> I'd be wrapping every one in a function to avoid the ugly creation
> of blobs.

Yes. It sucks for direct use. People have pointed out that the design
works for bindings since it's easy to add new options. So my
recommendation is to use CZMQ.

> I think it's a "cheat" to pretend that 0MQ only has a few functions in it's
> API. Every socket type is actually a distinct factory

Indeed. It's just yet another way of creating different functions.

> I guess in summary: if you're going to make a new C API, and deprecate the old
> one, we might as well re-examine the whole structure.

That is exceedingly dangerous for several reasons. First, you scare
people who depend on, have learned, the old API. Second, you will
enter endless discussions over rather minor details (bike shedding,
peek vs. getopt style). Lastly, you will break or at least force work
on dozens of language bindings.

There has to be great value in such large changes. Not proven. For
small changes, it does seem a fair tradeoff.

> YMMV: no point doing a new API with only a couple of minor changes.

My advice is to document your ideas somewhere so they can be discussed
and taken as a plan.

But my advice is also to _absolutely_ not aim for large, disruptive
changes. One thing at a time.

-Pieter