[zeromq-dev] Regarding java binding of 0MQ.

[Martin Sustrik]

Hi guys,
> When I suggested two variant of Poller.poll() method, my only purpose
> was to mimic the core libraries, which means less learning curve for
> new users. Also I think it makes sense if we combine the functionality
> of two methods in one, because current Poller.poll() is almost useless
> if we do not set timeout before calling it (may be I am missing any
> useful use-case where poll() can be called independently). But doing
> that will seriously break the existing semantics of
> poll()/[gs]setTimeout methods.
> Considering this I suggest:
> 1. Poller.poll() method with default behavior to wait indefinitely.
> 2. Poller.poll(timeout), with clear documentation that for timeout =
> -1 it will wait indefinitely otherwise it will wait for specified time
> before method call will return if no events are available.
> 3. deprecate Poller.[sg]etTimeout and to prevent existing code to
> break, fallback to previous behavior if user explicitly calls such
> methods before calling poll(), that is poll() will wait for given
> time-period. That leaves only one problematic case; if there is
> existing code which uses poll (without setting timeout) to check any
> immediate events available. I am clueless about this scenario.
>    
What's being discussed here is how to do a backward incompatible change.

The problem with that kind of thing is that you are going to break 
unknown number of applications and cause pain to lot of people that way.

Thus, the goal is either to avoid backward incompatible changes or, if 
refactoring of API is badly needed, join all the API changes into a 
single release, so that users have to experience the pain once only.

It's also important to provide a good rationale for the way the API is 
going to look like, otherwise it could easily prove inadequate and cause 
more changes to API and yet more pain to the users.

Additionally, it is good to separate the pieces that are unstable or 
likely to be changed in the future from the stable core functionality. 
This can be done either by moving it to a different package, marking is 
as "experimental" or somesuch.

In 0MQ core the strategy is to keep backward compatibility unless the 
major version number is changed. In the meantime, the 
backward-incompatible changes to the API are gathered on a wiki page 
(http://www.zeromq.org/docs:3-0#toc2) to be introduced in new major 
version (0MQ/3.0).

Martin