deferrable bodies in Rainbows!

James Tucker jftucker at
Sat Dec 26 20:21:35 EST 2009

On 26 Dec 2009, at 23:27, Eric Wong wrote:

> Moving to rainbows list
> James Tucker <jftucker at> wrote:
>> Eric - I had a report from one of the async_sinatra users who tried
>> out rainbows with EM, and found that the API didn't actually line up
>> with what Thin was doing. I really want to devote some more time with
>> this but I've been very busy. Sadly due to this I don't want to say
>> stop, but, well, I want to say please check existing apps against it.
>> I guess could you check async_*.ru from
>>*.ru, as from
>> what was reported, they're not working with the rainbows
>> implementation of the deferrablebody hacks.
> Hi James, thhanks for the heads up.
> Rainbows! doesn't handle deferrable bodies yet (I didn't look closely enough
> the first time around), so it can't do everything Thin does with EM, yet.
> It's already in the TODO, I'll make a mental note to work on it sooner.

Making this stuff work correctly in sync and async is one of the things that kills a style api, particularly for an abstracted IO layer like eventmachine (where you can't extract and hand out the raw IO without causing signficant complication + problems (we're never gunna support read(3) and EM buffered reads in concurrently under EM for obvious reasons)). This means such APIs can be problematic to implement properly, forcing people to buffer and pack in StringIO and whatnot. There are some more hacks one can do ofc, but I'd rather come up with an API that's good for all, whilst still being performant (this is possible, I am certain).

Sorry for yet another rushed reply (starting to feel real bad about that over here) :(

P.S. This S/MIME rejection is really starting to grate me, I'm wishing had the ability to forcibly stop doing that for specific addresses, but their S/MIME support is as embedded as most other clients (for mostly better, and occasionally worse).

More information about the rainbows-talk mailing list