Experimental: async-rack

Experimental: async-rack

[Konstantin Haase]

Hi everyone.

I just wanted you to know that I wrote a plugin for rack making all
the middleware that ships with it aware of env['async.callback'], as
supported by thin and a couple of other servers.

I would really appreciate some feedback: http://github.com/rkh/async-rack

Am I heading in the right direction?

Is making rack fully async still somewhere on the agenda?

Will async.callback become part of the official rack specification?
(Is there a specification for it at all, anywhere?)

Konstantin

Re: Experimental: async-rack

[James Tucker]

[-- Attachment #1: Type: text/plain, Size: 2543 bytes --]


On 9 Mar 2010, at 00:13, Konstantin Haase wrote:

> Hi everyone.
> 
> I just wanted you to know that I wrote a plugin for rack making all
> the middleware that ships with it aware of env['async.callback'], as
> supported by thin and a couple of other servers.
> 
> I would really appreciate some feedback: http://github.com/rkh/async-rack
> 
> Am I heading in the right direction?

In terms of how to do it, yes.

How useful this stuff will be is a completely separate question, the problem being two fold:

1. Most of the support load for async stuff is people doing it before they even know /why/ they're doing it, they have little to no experience with co-operative scheduling, and they then expect stuff like middleware to work, and to be able to write their entire app asynchronously. There's so much fail encoded in this stuff I don't quite no where to start, but the best advice I can give people is do what I do, and only use async actions for stuff that really really needs it, anything else is insane. Your efforts to make the middlewares work will be useful to some, but I'd like to avoid it ever suggesting that this makes it sensible to build entire apps on the API.

2. Most of the time, when using async actions, I actually want to skip most of the middleware. Async actions are useful for actions that are highly wait bound (be it IO, Queue, or Logic wait), and I log them separately, host them separately, and manage the whole internal stack in a much better engineered fashion for the specific purpose they're servicing. Generally this kind of area not only doesn't need boilerplate, but actually doesn't want boilerplate.

It's also worth noting whilst on this topic, that I generally write the libs that feed async actions as standalone libraries first, and later on simply wrap them in an async action container, be it a rack app or an async_sinatra app.

> Is making rack fully async still somewhere on the agenda?

Not using this method.

> Will async.callback become part of the official rack specification?
> (Is there a specification for it at all, anywhere?)

No. It is not appropriate as a long term API.

Many folks I've been talking to have been persuading me to shift the async stuff out into a separate project entirely. (keeping some API parity, and probably supporting embedding rack middlewares under a sync'ing middleware).

This may be the best approach, as this project receives enough support load without adding the complexity of async and scheduling into the mix.


[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 3679 bytes --]