Re: WSAPI replacement draft

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

?Okay, going through the proposal with a more finely-toothed comb right now 
as I'm writing [my fork](http://gist.github.com/794881), I have more 
in-depth feedback:

Version:
======================
My fork uses 0.1.0 as a version number. Even if the draft is supposed to be 
completely informal, putting a version number you would ever expect to see 
in production on a draft you would not is a bad idea. [It shouldn't say it's 
ready until it is.](http://testtrack4.com/wiki/Pardon_Our_Dust)

Things that are ambiguous:
======================
- According to the Response Body section (which doesn't list strings as a 
response type, even though that's what's used in the example in the 
"Interface" section):

"When this is returned from a request handler, each value is sent to the 
client, in sequence, without being transformed in any way."

Does this mean that the strings will be concatenated to form the response 
body, and does "without being transformed in any way" preclude the CRLF line 
ending normalization required for HTTP?

Things my fork doesn't keep:
=======================
environ.serverhost
------------------------
It's redundant with headers.host (which, as Rack's documentation says, is a 
better place to look).

environ.approot
---------------------
If a middleware function is going to change "prefix", why can't it just 
define "approot" itself if its apps need it?

environ.input
------------------
Replaced with a straight "body" string that contains the POST body, since 
the only reason to make this a stream is to accommodate CGI.

-----Original Message----- 
From: Stuart P. Bentley
Sent: Tuesday, January 25, 2011 4:59 AM Newsgroups: 
gmane.comp.lang.lua.general
To: Lua mailing list
Subject: Re: WSAPI replacement draft

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