Re: WSAPI replacement draft

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

?More holes I'm finding as I write up the CGI transition table:
- It still needs basic/digest authentication support.
- "remotehost" should be explicitly set to an IP. Getting the host name 
should be either outside the scope of this interface (such as leaving host 
lookup to a function in "Lack" that can take the remote IP) making it 
another field, or a combination of the two (a function that takes no 
arguments and performs the lookup on request). Which way depends on how 
REMOTE_HOST is normally handled in other implementations.

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

?>Good idea as for the 0.x version number, but I explicitly had the
> version number as a *number* (as opposed to a string) for a reason - 
> namely, it's much easier to do comparisons with numbers than with strings 
> (you can explicitly do a "greater than" or "less than," and you can use 
> math.floor to get the minor version), and also I don't think that there 
> would really be "patch level" changes to the spec - just minor changes and 
> breaks-backwards-compatibility changes.

The thing is, (unless you're [Donald Knuth][1],) version numbers are
sequences of unsigned integers, not decimal numbers (see
http://en.wikipedia.org/wiki/Software_versioning#Sequence-based_identifiers).
If granular version comparison is such a big deal that it needs to be
supported at the interface level (usually, in the edge cases where you need
to check version, string.sub and string.find with tonumber will be more than
enough), you can keep the version as a table, and read the major version
number as environ.version.major (or environ.version[1]).

[1]: http://en.wikipedia.org/wiki/Software_versioning#TeX

> > Things my fork doesn't keep:
> > =======================
> > 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.

> Nope. For example: assume someone uploads a 4.2 MB photo to your photo 
> hosting site. You don't want the whole thing in memory at once (especially 
> if your site is particularly high-traffic) - much easier just to stream it 
> to a file in nice, manageable 4K blocks.

It was 28 hours in the morning when I wrote that and I was under some wild
sleep-deprived assumption that multipart bodies generated multiple requests
that were assembled at the application level.

I've put the input stream back in my latest revision (as the inputread()
function).

I've also made some embellishments to the spec for errorwrite().
--
Regards, Matthew "LeafStorm" Frazier
http://leafstorm.us/