[Web-SIG] Re: Bill's comments on WSGI draft 1.4

[tony at lownds.com]

> Because explicit is better than implicit.  Returning a "file-like" object
> can mean, "read all the data and send it as one block", or "read the data
> in arbitrary-size blocks and send them".  The application should say what
> it means!  Either:
>
>      return [filelike.read()]
>
> or:
>      yield filelike.read()
>
> or:
>      return iter(lambda: filelike.read(bufsize), '')
>
> or something else, according to the results it intends.  The server
> shouldn't have to *guess* which of these is meant.
>

Wouldn't servers be better equipped to send a file efficiently, rather
than the application?
The recipe for sending decent-sized chunks instead of line-sized chunks
just obliterated the fileno() optimization.

I'm specifically advocating that servers be required to use read() if they
can't use fileno(). When an application returns an open file object,
servers that send it out line by line (ie, as an interator) would be far
far slower than servers that use fileno(). So that technique wouldn't
really be portable across WSGI implementations. Using read() would make
returning an open file a viable technique on all WSGI servers.

-Tony