Hi Sam,
I just wanted to point out that the specification was meant to be optional and
this is why it includes the `env['upgrade.websocket?']` flag to indicate
support.
I don't think every server has to support Websockets - different server
architectures favor different tasks and performance isn't a one size fit all.
However, it's high time (if not a bit late) Ruby had better support for
applications that decide to use Websockets - which is, obviously, not all of
them (I doubt that many applications need them).
I think it's wrong that Websockets are so complicated to implement in Ruby and
Rack. The technology might be dangerous, but it does have it's uses (such as
large file uploads, inter-app micro-services, game servers... to name just a
few use-cases that survive HTTP/2).
- Bo.
> On Aug 8, 2016, at 21:08, Sam Saffron wrote:
>
> For the record Eric,
>
> We use unicorn at Discourse to serve concurrent long polls across 100s
> of hosted forums using hijack with zero issues using
> https://github.com/SamSaffron/message_bus
>
> I am not particularly enthused WebSockets and have blogged about my
> reservations, in an HTTP/2 world I am less clear about how they fit in
> except for some very niche uses.
>
> If this becomes a core Rack specification and now forces all Rack
> implementation to carry around websocket framing protocol and
> epoll/kqueue I would also be less excited.
>
> On Sat, Aug 6, 2016 at 5:37 PM, Boaz Segev wrote:
Michael said
>>> Unicorn is a forking webserver, not an event-driven or threaded
>>> webserver. Whether Unicorn ever supports the proposed standard or
>>> not, I wouldn't recommend it be used for typical applications that use
>>> WebSockets, as they usually involve persistent connections. Unicorn
>>> would quickly run out of worker processes capable of serving such
>>> connections anyway, so I question whether it's worth delving into the
>>> dirty details of IO syscalls.
>>
>>
Eric said
>>> Sorry, not interested, and definitely not touching centralized
>>> message boards :>
>>
>>
>> I totally understand and I thank you both for your time.
>>
>> -- Bo.
>>
