Re: WSAPI replacement draft

[Jim Whitehead II <jnwhiteh@...>]

On Sun, Jan 23, 2011 at 12:19 AM, Chris Babcock <cbabcock@asciiking.com> wrote:
> 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.

I'm going to tag onto Chris's responses for many things here, but I
want to say something about this. Your assertion that WSAPI is only
used by Kepler servers and applications just isn't necessarily true.
My entire production website runs as a single Lua script that uses
WSAPI. I don't use anything of the Kepler stack other than some of the
non-web related libraries, and WSAPI itself. I've run this server
under Lighttpd, Apache and a few other servers simply because its an
executable script.

That's the major advantage of WSAPI.. it already works everywhere.
That's not to say that something 'different' isn't a good idea, but is
it going to be much of anything other than a transformation or
different form of what WSAPI already does? Getting a 'standard' in Lua
is hard enough as it is it seems like it would be a bit tragic to
abandon one that we have =).

> 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?

I personally don't have all that much use for it until I see more. I
can already take and wrap a WSAPI application with whatever data
structure I'd like and access the data, while having the consistency
across the stack. I do this now and it makes my life easier.

> 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
>
>