[nanomsg] Re: ws transport
- From: Drew Crawford <drew@xxxxxxxxxxxxxxxxxx>
- To: "nanomsg@xxxxxxxxxxxxx" <nanomsg@xxxxxxxxxxxxx>
- Date: Sat, 29 Nov 2014 11:44:15 -0600
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:
