[zeromq-dev] Explicit patterns

Mark V mvyver at gmail.com
Fri May 28 03:18:59 CEST 2010

On Fri, May 28, 2010 at 12:30 AM, Martin Lucina <mato at kotelna.sk> wrote:
> sustrik at imatix.com said:
>> >> So your view is that there is no need to rename/fixup the socket type
>> >> names, that won't make things any clearer...?
>> >
>> > Yes, definitely.  I think it would confuse the situation.
>> I agree with Brian.
> +1

Hmm I actually quite liked what Pieter proposed - as a
messaging-architectures novice.
I've re-read what Pieter proposed, and the difference of opinion seems
deeper than naming.
Pieter proposed making patterns '1st class entities'.  With this
elevation (logical and consistent) naming of sockets and devices
becomes (in my mind) an issue.
It seems the objections are less about the naming, and more about
keeping sockets as the primary building blocks.

>From my POV: When I come to 0MQ I have a problem in mind.  The sooner
0MQ's building blocks can match my mental picture of the problem the
more likely I am to commit time and effort to addressing the
inevitable wrinkles.

I have a many-clients one-server application in mind.  There are other
latent behaviors, but they are not yet recognized as influencing the
architecture I choose.  I come to 0MQ wondering, "Is this worth
looking into?"

So my questions are:
If patterns are not first class building blocks how do I,
_more_easily/quickly_ 'recognize', using generic/ambiguous
sockets/device names that 0MQ fits my problem?
Otherwise, if patterns are first class building blocks, how do
generic/ambiguous socket and device names allow me to avoid time and
effort investigating socket/device features/behaviors not directly
relevant to my problem?

Or perhaps I've misunderstood the intent of the changes Pieter has canvassed?


> Pieter, a tutorial with examples is really missing right now so
> contributing one will be most appreciated. Provided we can find a way to
> get it into AsciiDoc format we can also bundle a version as e.g. a
> zmq_tutorial man page with the released tarball.
> My objective with the API reference is to keep it very much as a
> comprehensive "dry" reference manual. This would be complemented very well
> by a good tutorial + cookbook with examples.
> Patches to the API reference are welcome! The source is in doc/*.txt in
> Git.
> I will try to update and clarify the most problematic parts; after all it
> was written some time ago when we were still deciding on correct
> terminology for the main concepts with Martin.
> -mato
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev

More information about the zeromq-dev mailing list