[nanomsg] Re: ws transport
- From: Garrett D'Amore <garrett@xxxxxxxxxx>
- To: nanomsg@xxxxxxxxxxxxx
- Date: Sat, 29 Nov 2014 10:20:31 -0800
Funny thing is, I think that fork already occurred in some way. You could view
“nanomsg” as a philosophical fork from zeromq.
To put it another way, if a very rich set of capabilities is valuable to you,
and you don’t see a problem with increasing complexity to achieve higher levels
of capability and integration, then why would you choose nanomsg over ØMQ?
One of things I particularly like about nanomsg is that it *doesn’t* try to
solve all the worlds problems, but has taken a step back to solving a much
smaller set (and arguably less contentious, and easier to solve) of problems
than ØMQ.
I would argue that some of these philosophical decisions are also at the root
of Martin’s decision to C instead of C++ — to me at least it seems a drive
towards KISS rather than a drive for features.
The one rational explanation I see for nanomsg instead of ØMQ, while still
preferring the higher levels of integration afforded by ØMQ, would be a need to
interact with existing nanomsg clients or servers. But at that point, do you
really need all that other richness, given that its unlikely that those other
clients/servers are doing anything other than stock nanomsg themselves?
- Garrett
> On Nov 29, 2014, at 9:44 AM, Drew Crawford <drew@xxxxxxxxxxxxxxxxxx> wrote:
>
> Fwiw I think the systemd comparison is very apt.
>
> Some of us see a library that can be greatly improved to handle much more
> complex use cases through increasing integration.
>
> Some of us see a simple library that has worked for us so far.
>
> My concern is that feelings may be strong enough to fork over this issue.
>
> In at least 3 dimensions, an accurate analogy.
>
> Sent from my iPhone
>
>> On Nov 29, 2014, at 11:36 AM, Garrett D'Amore <garrett@xxxxxxxxxx> wrote:
>>
>>
>>> On Nov 29, 2014, at 9:23 AM, Drew Crawford <drew@xxxxxxxxxxxxxxxxxx> wrote:
>>>
>>>
>>> But as long as we view each proposal with the lens of “is this too
>>> complicated” we’re doomed to be a slightly cleaner, feature-poorer subset
>>> of zeromq.
>>
>> It is clear to me at least, that not everyone here desires to achieve
>> feature parity (or beyond) with zeromq.
>>
>> As for me, I view nanomsg/SP as a building block — but I also like the UNIX
>> philosophy — do one thing and do it well, rather than feature richness in a
>> single component.
>>
>> So for example, I’m not a fan of proposals to bring some other kind of
>> message packaging or framing to nanomsg — binary transports ought to be fine
>> for everyone, and folks who want to do framing above that should use a
>> higher level library, IMO.
>>
>> Linux followers will recognize the difference of philosophies as the same
>> differences found between systemd adherents and detractors.
>>
>> I’m a little curious as to why a standard websocket library was not seen as
>> up to the task. Implementing pure websocket for nanomsg is probably
>> relatively trivial (its just a few headers to parse, and afterwards becomes
>> TCP, right?) But being fully capable with SSL support is probably very much
>> a non-trivial problem, and may be better deferred to a standard library.)
>> But, perversely, tcp+tls may suggest the reverse.)
>>
>> - Garrett
>>
>>
>
Other related posts:
