lua-users home
lua-l archive

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

On 01/25/2011 12:24 PM, Stuart P. Bentley wrote:
?Okay, going through the proposal with a more finely-toothed comb right
now as I'm writing [my fork](, I have more
in-depth feedback:

My fork uses 0.1.0 as a version number. Even if the draft is supposed to
be completely informal, putting a version number you would ever expect
to see in production on a draft you would not is a bad idea. [It
shouldn't say it's ready until it

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.

Things that are ambiguous:
- According to the Response Body section (which doesn't list strings as
a response type, even though that's what's used in the example in the
"Interface" section):

"When this is returned from a request handler, each value is sent to the
client, in sequence, without being transformed in any way."

Does this mean that the strings will be concatenated to form the
response body, and does "without being transformed in any way" preclude
the CRLF line ending normalization required for HTTP?

Concatenated to form the request body. What I meant by "without being transformed in any way" was, "no separators are applied." Also, as far as the CRLF issue, I'm pretty sure that only applies to the headers. (After all, what would happen if you transferred a binary file that just happened to have a "10" byte in it?)

Things my fork doesn't keep:
It's redundant with (which, as Rack's documentation says,
is a better place to look).

The original purpose of this was for being able to quickly determine subdomains. Of course, it's probably easier just to have the base domain be handled by the application's configuration if necessary, especially when you consider virtual hosting.

If a middleware function is going to change "prefix", why can't it just
define "approot" itself if its apps need it?

Yeah, the distinction between "approot" and "prefix" is a bit unclear (especially since my plans for the server I'm writing have it literally calling into a LASI handler as soon as the request is parsed.)

Both this and environ.serverhost were based on the "Super Secret WSGI Replacement." The author, Armin Ronacher, has a lot of experience with WSGI, so I assumed he had a specific use case for it.

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.

Regards, Matthew "LeafStorm" Frazier