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

[James Tucker <jftucker@gmail.com>]

On 17 Dec 2009, at 08:47, Eric Wong wrote:

> James Tucker <jftucker@gmail.com> wrote:
> <snip>
>> Agreed. I'm not saying "must", but I would like to request that if
>> you're going to try and support asynchronous models, please do it for
>> real, rather than hacking it in the way we're having to in rack / thin
>> / flow / etc. The more hacks we end up with, the more people get the
>> impression that this is "the right way". As it is, the lack of
>> protocol - app layer separation in for example, eventmachine
>> applications is appalling, and something from which the community may
>> never recover. The same kind of history is about to repeat itself in
>> the async + long running cycle web areas - if it hasn't already gone
>> past the point of no return.
> 
> I'm glad I'm not alone in feeling the current async add-ons in Rack
> servers are very hacky.  I'll leave async callback support out of
> Sunshowers until we can have an async spec that's as elegant the
> rest of Rack.

Yup, this is part of the reason I refused to release my Thin patches for such a long time. They're not graceful at all. Unfortunately, after some of the heavy lifters had been using it in production for a while, and it was becoming a core component of some of the nanite infrastructure, the amount of noise it was causing in my inbox overrode my desire to hold back the unfortunate API from the public as a whole. It's getting an increasing amount of attention, for better or worse at the moment.

>> Like I say, I could just be too much of an efficiency ideologist. If
>> you don't have the demand / desire for it, then you may not have a
>> good reason to put the effort in - certainly there's nothing else in
>> the middle-ground space that you're filling presently, so I don't
>> think you're "losing a significant market" by not doing so. As it is,
>> I know of a couple of handfuls of apps either in production or close
>> to production doing relatively high load async web work in ruby, and
>> those folks seem to have done alright with the nasty hack that is the
>> current async.callback and deferrable body apis. Bigger deterrents to
>> this area actually exist outside of the web server domain itself, as
>> the 1.2+ Thin api works just fine, by contrast, there's no ORM or
>> process framework for doing async work well, and the closest thing
>> there really is to a "nice" async api in ruby open source at present
>> is the sequel monkey patches that Aman published iirc with em-mysql.
> 
> Heh, I don't know of a single public site using Rainbows! (in any form)
> nor Sunshowers in production, yet.  It's winter right now and probably
> not the season for Rainbows! and Sunshowers :)

:D

I don't know if you follow the Thin mailinglist, but there's a discussion relating to some of this stuff going on over there that you might find useful to read through, just from the point of view of how general community members tend to approach the idea of async, and the common misconceptions etc. My really long term goal is to get the APIs down to something simple enough that these issues don't come up, but part of this is also the requirement for a new breed of framework that's not built around inherently synchronous ORM systems.

>> P.S. it's late, so i apologise if this is too wordy/vague.
> 
> Nope, I pretty agree with everything you said and will look forward to a
> Rack 2.0 spec that covers async nicely.  Meanwhile, I'll keep the focus
> on 1.9 Fibers since they're largely "good enough".

Absolutely, I know that oldmoe has had some great success using them in NeverBlock, and who knows, if ruby can be made to be more efficient at stack wrangling one day, then maybe they could defeat the async approach. Certainly for the foreseeable decades, that's not going to happen though :)

I'll be sure to include you in any future discussions on the APIs discussed.

> 
> -- 
> Eric Wong