[zeromq-dev] ZMQ_LINGER socket option
gonzalo diethelm
gdiethelm at dcv.cl
Mon Oct 18 23:19:55 CEST 2010
> > Right. My question was: should the definition and use of this in 0MQ
> > itself (zmq.h and options.cpp) be protected in any way with VERSION
> > macros?
>
> No. We are using branches and tags to manage the versions.
>
> Individual bindings are free to use branch/tag mechanism as well,
> however, ZMQ_VERSION macros are introduced with the idea that binding
> developers are not working full-time on the project and don't have
> sufficient resources to administer the process of tagging, branching
and
> version management.
>
> Thus they can use ZMQ_VERSION that is cheap and kind of nasty :)
Ok, agreed. Minor thing: bindings for dynamic languages are usually done
this way; in the Java world, you are supposed to have a single binding
that can work with all versions of the underlying library.
Now, a request for suggestions: until now I am returning void / -1 for a
Socket.setXXX / Socket.getXXX when the XXX is not supported by the
underlying 0MQ library. But this makes it kind of hard to know if you
are getting a -1 as an error flag or a real value; even harder for
setXXX, where it will simply return. I guess I should really throw an
exception to make it really obvious it is failing. The question is: what
is the proper exception for these cases?
And also: be advised that, should I change this, I would be changing the
public interface for the Java binding (and I am not ready to split it
into maint and master yet...). I know, a pain in the rear. Better now
than later.
--
Gonzalo Diethelm
More information about the zeromq-dev
mailing list