To go into more detail:

Calling zproxy_pause, zproxy_resume, and zproxy_terminate on libzmq 2.2 -> 4.0 
does not do anything, as zmq_proxy_steerable was added after 4.0.

I mulled over three approaches to address this:

1) Have an #if ZMQ_VERSION macro that simply removed those methods if czmq is 
built against a libzmq does does not have zmq_proxy_steerable
2) Throw an assert if those methods are called when czmq is built against a 
libzmq that does not have zmq_proxy_steerable
3) Do nothing, and return a -1 when those methods are called when czmq is built 
against a libzmq that does not have zmq_proxy_steerable

My gut was leaning  towards going with option #2, but I talked myself into 
going with option #3 rationalizing that it was "more backwards compatible".

However, since the calls won't actually do anything except return an error code 
- perhaps exploding via an assert is a more assertive communication that the 
API user has tried to do something that can not work.  Thinking about it, I 
can't think of a scenario where I would want my code to call these functions 
when czmq is built against a libzmq that can't support them.

Lindley and Pieter - thank you both for your feedback!

Brian

-----Original Message-----
From: [email protected] 
[mailto:[email protected]] On Behalf Of Pieter Hintjens
Sent: Thursday, December 05, 2013 11:12 AM
To: ZeroMQ development list
Subject: Re: [zeromq-dev] zproxy (hopefully) improvements

On Thu, Dec 5, 2013 at 2:52 PM,  <[email protected]> wrote:

> I'm of the opinion that asserts should only be used to signal an internal 
> problem with the library. Any external interface should instead use error 
> codes if the input is detectably bad. So the question becomes, if you build 
> against a lower version of ZMQ, is that an error or does it just reduce your 
> capabilities? Can you require a minimum version, and check this at init time?

CZMQ already uses very extensive asserts to catch bad arguments.
Building against a lower version of libzmq is fine. Trying to use non-existent 
features is bogus, IMO.

-Pieter
_______________________________________________
zeromq-dev mailing list
[email protected]
http://lists.zeromq.org/mailman/listinfo/zeromq-dev
_______________________________________________
zeromq-dev mailing list
[email protected]
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Reply via email to