On Thu, Jul 29, 2010 at 10:03 AM, Pieter Hintjens <[email protected]> wrote:
> 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. > > Fantastic! Thanks for the clarification. Cheers, Brian > -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 > > -- Brian E. Granger, Ph.D. Assistant Professor of Physics Cal Poly State University, San Luis Obispo [email protected] [email protected]
_______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
