Re: WSAPI replacement draft

[Chris Babcock <cbabcock@...>]

On Sat, Jan 22, 2011 at 3:19 PM, Matthew Frazier
<leafstormrush@gmail.com> wrote:
> Hello, everyone.
>
> A few days ago, I wrote a blog post [1] detailing my opinions on server APIs
> like WSGI, WSAPI, and Rack. As promised in the post, I have written the
> first (very early) draft of LASI, the Lua Application/Server Interface [2].
> (Sorry if the definition lists are a bit hard to read, Github doesn't play
> well with RST.)
>
> The major reasons for this are explained in the blog post - namely, I think
> that the CGI-inspired style of existing gateway interfaces doesn't really
> work with today's servers and applications. Also, WSAPI is kind of
> underspecced, and really only used by Kepler servers and applications.

The advantage of the CGI-inspired style is that it maps consistently
though all layers of the stack. Debugging web applications can be
difficult. We haven't really needed HTTP_ALL_CAPS since fast CGI, but
it has persisted anyways because developers want to make the
applications agnostic of the deployment without adding a
computationally expensive extraction layer to the CGI deployment. In
other words, the rationale behind that syntax for WSGI still applies
for now.

I suspect that these server specs may rely on transparency through the
HTTP protocol and application stack for definition and extensibility.
If something is added to HTTP headers or to the environment - for
example, Geolocation data from a plug-in to Apache running as a proxy
- then the application server doesn't need to know about it to allow
the application to access that data.

> Anyway, before I start writing code, I would enjoy some feedback, especially
> on:
>
> - What do you think about the ideas in the blog post? Do you think a new
> style of interface is necessary?

Web framework fragmentation was ugly for Python. I'm not entirely
convinced of the necessity of a new API. My most specific concern
would be how will this new spec/interface be maintained?

> - Do you think that my specific concerns about WSAPI are valid?

My observation has been that web applications are a small portion of
the use cases for Lua. The two ways to interpret this would be:
  a) There's not a need for a new spec because there isn't an audience for it.
  b) The right spec could do for Lua what Rails did for Ruby.

I don't mean to impute the normal values to either of those
statements. In my opinion, "a" is a non-argument and "b" is a mixed
blessing. ;)

> - How would you pronounce LASI?

Lay-SEE'

> - Can you think of a better name?

Not really.

> - Did I forget anything important in the spec?

Nothing obvious.

> - Server developers: is there anything in the draft that would be
> particularly tricky to implement in terms of HTTP?

Parsing HTTP is dirt simple and you don't have to look for (or write)
much documentation. The variable names are the same from the HTTP spec
to the application, which is nearly zero overhead. There's nothing
tricky about mapping HTTP variables to an object syntax, but any
abstraction level is overhead that a direct rendering doesn't have.

> - Application and library developers: is this something you would be
> comfortable working with?

It's totally sweet. The only problem with it is that I already know
how to work with the CGI-style so in my mind I will always be doing
the translation.

> [1] http://leafstorm.us/articles/web-server-apis-today/
> [2] https://gist.github.com/791517
> --
> Thanks, Matthew Frazier

The biggest thing I see going for the spec is the ability for the
application to communicate about its state mechanisms to the server.

Chris
--
51st century guy