A new response class, HttpResponseSendFile is added for that
purpose.

In my humble opinion it should visibly and loudly break if
the handler does not support sendfile() -- I want to know if
my files are served efficiently or not. Conversely, it
should not degrade to an ordinary HttpResponse behaviour of
opening the file in Python and returning it's content (as an
iterable).

Under these conditions, HttpResponseSendFile implementation
is simple and clean. It's always handled specially in
handlers. If some third-party handler is unaware of it, it
should break as per the rationale given above.

However, that's exactly what Jacob was concerned about (i.e.
he raised backwards-compatibility concerns with existing
third-party handlers and requested that the degraded
compatible behaviour should be supported).

HttpResponseSendFile is a new feature that does not exist in
1.0.X. Nothing breaks by adding it per se. People who
attempt to use the new 1.1 feature with old third-party
handlers should expect it to break -- neither will aggregate
code work with 3rd-party db backends that haven't been updated
for 1.1.

If compatibility is required, the implementation will not be
as clean and straightforward:  unneccessary clutter
is required to duplicate the behaviour that's already
available in ordinary HttpRequest (e.g. duplicated open()
calls for the same file in different code paths -- smells
bad to me).

Thoughts?

No compromises there,

 :render => { :nothing => true }

(don't return anything in the content).