Re: [ANN/RFC] LMGTWTY - Web Sockets for Rack+Rainbows!

[James Tucker <jftucker@gmail.com>]

On 15 Dec 2009, at 04:37, Eric Wong wrote:

> James Tucker <jftucker@gmail.com> wrote:
>> On 14 Dec 2009, at 18:42, Eric Wong wrote:
>>> James Tucker <jftucker@gmail.com> wrote:
>>>> On 14 Dec 2009, at 00:23, Lakshan Perera wrote:
>>>>> This is awesome! Thanks for coming up something like this, in a
>>>>> short period of time.  I hope this would be part of Rack, which
>>>>> would enable all Ruby Frameworks to work effortlessly with
>>>>> WebSockets.
>>>> 
>>>> I really want to work out an abstraction away from IO instances, #read
>>>> and #write for this stuff. It's highly coupled, getting in the way of
>>>> tests, and heavy lifting environments. I have big plans for Rack 2.0
>>>> to remove all IO that has not been properly abstracted and decoupled
>>>> from implementation details, but that's a long way off, mostly due to
>>>> lack of time and incentive. In the meantime, I can implore you all to
>>>> take steps in the right direction :-)
>>> 
>>> Huh?  I don't see what the problem with IO instances/semantics is,
>>> especially with the availability of StringIO for testing.  "rack.input"
>>> is clearly specified and works fine as-is IMHO, though the rewindability
>>> requirement does add some unnecessary overhead.
>> 
>> I disagree with "works fine". It does not work fine with Thin, in
>> fact, on the contrary, it forces some real ugliness into the system. I
>> also think that StringIO is a really unfortunate thing to have to
>> resort to, as it has so many short comings.
> 
> Mind elaborating?  I do not see what's ugly about it[1].

Sure. It forces authors to several (bad) APIs options for handling complex IO scenarios.

1. Buffer the entire request and then republish to the application
2. Pass forward the raw IO

Both of these options put significant restrictions on the ability to do complex (and efficient) scheduling.

1. Prevents the ability for the request to begin processing asynchronously to the receipt of the request body without a custom future of some kind. Adding a future is not a bad solution, but, it's so far out from everything else at the moment because the rack spec says use an IO. The StringIO could be used as a future, however, the reality is there's no way for the server to tell the app that the future is ready for consumption. This is a total lack of proper encapsulation that would be required for improved scheduling and IO handling.

2. This approach forces the application developer to be responsible for buffering and scheduling - something which application authors typically know nothing about. The result is common use of slurp approaches, and sometimes even multiple reads of the same buffer.

> I haven't used Thin with uploads much, but I do have apps that handle
> lots of large uploads (via curl -T to make PUT requests) with Unicorn
> and Mongrel before that.
> 
> StringIO isn't perfect (can't stat/select/chmod on it), but for
> Rack tests it's plenty alright...

Sure, for trivial, low efficiency, slurping, synchronously scheduled work, it's fine, and I do use it for that quite frequently.

> [1] - I admit to having a Unix bias here where
>      nearly everything is a file, or ought to be :)

We're not stream processing here. It's a request/response cycle. And they aren't files, they're sockets.

Unix philosophy is good for the shell, but it doesn't extend well into efficient systems. The simplest proof for this is the existence of kqueue, epoll, completion ports, and eventlets.

To optimise for efficiency or for performance (they needn't be the same), it is absolutely required that abstractions move away from strictly synchronous and external-lock scheduled IO (like group select or per-socket select, etc).

> 
> -- 
> Eric Wong