[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: WSAPI replacement draft
- From: "Stuart P. Bentley" <stuart@...>
- Date: Tue, 25 Jan 2011 04:59:49 -0800
?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?
- 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).