[zeromq-dev] zmq-socket name aliases

Pieter Hintjens ph at imatix.com
Thu Jul 29 19:03:19 CEST 2010

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.


Sent from my Android mobile phone.

On Jul 29, 2010 6:47 PM, "Brian Granger" <ellisonbg at gmail.com> wrote:

On Wed, Jul 28, 2010 at 3:36 PM, Pieter Hintjens <ph at imatix.com> 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.,
* 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
> > zeromq-dev at lists.zerom...


Brian E. Granger, Ph.D.
Assistant Professor of Physics
Cal Poly State University, San Luis Obispo
ellisonbg at gmail.com

zeromq-dev mailing list
zeromq-dev at lists.zeromq.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20100729/619a576c/attachment.htm>

More information about the zeromq-dev mailing list