Re: WSAPI replacement draft

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

On Sun, Jan 23, 2011 at 2:37 AM, Matthew Frazier
<leafstormrush@gmail.com> wrote:
> On 01/22/2011 07:28 PM, Jim Whitehead II wrote:
>>
>> 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.
>
> Whoops. I guess that was a bit of a fail. Though when I said "Kepler
> servers" I was referring more to "Kepler connectors," like the CGI and
> FastCGI connectors they maintain in the WSAPI library. (I probably should
> have clarified that more.) About the only WSAPI connector I have seen not
> part of a Kepler library is the one with HTTP.lua (though if I'm wrong about
> that too feel free to let me know).

I may be a bit of anomaly in that I don't use any connectors at all, I
just use the wsapi.run_cgi function with my script. This is the
pattern I've used with all of my web apps, as I like to avoid clogging
the stack with layers upon layers of libraries.

>> 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 =).
>
> I'll concede that the job it does is very similar to WSAPI. The main
> difference (besides the API style) is that it's not bound to a specific
> library for most of its implementation. If you look at the manual page for
> WSAPI, there are about six paragraphs and a code sample that actually
> specify the interface, and even then it's very loosely defined. It seems to
> me that it was mostly designed so that servers could have an interface to
> run the Kepler libraries, because there's very little specified on what's
> available to the application side.

You're right in that the specification is undefined because its really
defined by the CGI interface itself, you get the variables that are
set by the web server and your responses must also be crafted
accordingly. Having something that moved things around or makes them
more accessible certainly needs a specification and what you have
looks like a good start.

>>>> - 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.
>
> A reasonable viewpoint. I don't expect this to take over from WSAPI
> immediately, even once there are servers and libraries for it.

I think getting the web server to implement this is going to be the
difficult thing.. given the path of least resistance is still the CGI
protocol, but I look forward to watching the progress. Please let us
know when you progress beyond the specification stage.

- Jim