Re: WSAPI replacement draft

["Stuart P. Bentley" <stuart@...>]

?Speaking as a Lua developer who's been trying to break into web development 
but hindered by WSAPI, here's my feedback:

- What do you think about the ideas in the blog post? Do you think a new
style of interface is necessary?

I think a new style of interface is only necessary only in the sense that 
designing a new API to imitate CGI is completely backwards and unnecessary 
(especially in cases like WSAPI where the fields are subsequently 
undefined). The real necessity is to mirror HTTP, which the example you 
provide does better than the CGI-style interfaces we have now.

However, it seems a lot of web developers do tend to come from some manner 
of CGI background, and it does have a decade of introductory material using 
it as the lingua franca. The solution here is to keep a prominent appendix 
in the documentation of any new API, with how the traditional CGI variables 
correspond to LASI.

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

The biggest problem I have with WSAPI is that it demands prerequisite CGI 
experience to work with, but the way that it requires [disassembly of 
pre-assembled CGI](http://testtrack4.com/wiki/Some_Assembly_Required) on 
non-CGI platforms like Xavante is problematic too.

- How would you pronounce LASI?

Lassie.

- Can you think of a better name?

LASI is a good name that trumps WSAPI on many points:
* It explicitly defines Lua in the name
* It's pronounceable as a word
* Its role is clear as an Application/Server Interface (both in the 
programming and communication senses)

- Did I forget anything important in the spec?

A clear explanation of every key in relation to the equivalent CGI would aid 
accessibility, in addition to in-line examples of each key for a sample 
request. I'll see if I can make a fork that implements this (I just got a 
github account a couple days ago).

Also, why can't the response body just be a string?

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

Doesn't look like it, but I'm not a server developer.

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

I'd certainly be more comfortable working with this than I would with WSAPI, 
largely because it's better documented and properly orthogonal (keeping its 
goals well-defined and not, say, specifying "helper libraries" that are 
better defined by each middleware implementation).