[zeromq-dev] zmq-socket name aliases

[Brian Granger]

On Thu, Jul 29, 2010 at 10:03 AM, Pieter Hintjens <ph at imatix.com> 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" <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.,
> 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
>> > zeromq-dev at lists.zerom...
>>
>
>
>
> --
>
> Brian E. Granger, Ph.D.
> Assistant Professor of Physics
> Cal Poly State University, San Luis Obispo
> bg...
>
> ellisonbg at gmail.com
>
>
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
>


-- 
Brian E. Granger, Ph.D.
Assistant Professor of Physics
Cal Poly State University, San Luis Obispo
bgranger at calpoly.edu
ellisonbg at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20100729/d78a5535/attachment.htm>