lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index] 

On 01/22/2011 07:19 PM, Chris Babcock wrote:

On Sat, Jan 22, 2011 at 3:19 PM, Matthew Frazier
<leafstormrush@gmail.com>  wrote:

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.
Yeah, you have a point. CGI is somewhat marginalized now, and there are some serious problems with it (which is part of why I designed the spec to be not like CGI), but as long as there are shared hosts who like to advertise language support without really putting any real effort into it, CGI will still be around. And it certainly is easy to deploy WSAPI on top of CGI - just add an __index method to the environment to look up environment variables.
I guess it's mostly a question of whether it's more important to have implementation easier for CGI-type servers or for the new application servers, because you can get a spec that works either way. 


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?
Still working that out. My starting plan is to develop a server that "speaks" LASI internally, and a reusable set of components for it (kinda like Werkzeug or Rack) - though of course the spec would be maintained separately from both of those. From there, I guess we'll just have to see what happens.
(Of course, if you look at WSGI and Rack, both of those have only had one major revision since their inceptions, and WSGI's was because a new version of Python was released that broke everything.) 


- 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. ;)
Oof...I'd hate to have anything taking over Lua the way Rails took over Ruby. (And I'd definitely hate to be anything like DHH.) Anyway, there's no way to determine if LASI is "the right spec" without deploying it and seeing what happens. 


- 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.
One of the goals of the spec was getting from the parsed HTTP request to the environment as quickly as possible. 


- 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.
That's a problem with pretty much any new tech, really. Though it's very similar to the request abstractions used by existing Web frameworks. 


The biggest thing I see going for the spec is the ability for the
application to communicate about its state mechanisms to the server.
Sorry, but I'm not sure I quite get what you're talking about here. Could you elaborate a bit? 


Chris
--
51st century guy


--
Thanks for the feedback,
Matthew Frazier