Re: WSAPI replacement draft

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

?>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/