The APIs are a contract and won't break unless there is overriding consensus that its necessary. That seems very unlikely from here on, barring small tweaks like renaming confusing socket types.
Possibly an extended api to access raw sockets. I believe there are use cases for these but they should not mess with the existing patterns, which are proven, and stable. That is a committment iMatix is happy to make. -Pieter Sent from my Android mobile phone. On Jul 29, 2010 6:47 PM, "Brian Granger" <[email protected]> wrote: On Wed, Jul 28, 2010 at 3:36 PM, Pieter Hintjens <[email protected]> wrote: > > On Wed, Jul 28, 2010 at ... Interesting, I have ben thinking about this lately as well. The reason I started to think about this is that there are a core set of capabilities that 0MQ sockets have like: * HWM handling (discard or block) * Outbound routing (multcast, load balance, identity based routing, etc., topics) * Inbound routing (fair queing) * Number of peers (1, many) * Directional (R, W, RW) * Sync/async, etc. All of these things could be options to a lower level socket object. This would allow the building of other socket types as well as the current types. BUT, I am worried that this is too much flexibility and that 90$ of the combinations don't make sense. So, to go this direction, I think we would have to have a really strong reason to do so. What could people do, that they actually need to do, that they can't now? > > However... while this may appeal to those of us who like to make > things... it would IMO be... Yes, whatever happens in 0MQ3, I hope that the user/dev facing APIs can remain the same or evolve gradually. 0MQ has gained a ton of momentum and we and others are now building real apps with it. While I am all for incremental evolution of the API to improve features and address limitations, I think major API breakage or redesign would be a bad thing at this point....such as happened to AMQP with the 1.0 spec... > > > > > We learned this lesson with AMQP which does not give you patterns but > > instead building blocks... > > > _______________________________________________ > > zeromq-dev mailing list > > [email protected]... > -- Brian E. Granger, Ph.D. Assistant Professor of Physics Cal Poly State University, San Luis Obispo bg... [email protected] _______________________________________________ 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
