On Jun 22, 9:52 am, Malcolm Tredinnick <[EMAIL PROTECTED]>
wrote:
> On Thu, 2007-06-21 at 07:45 -0700, Ilya Semenov wrote:
> > Malcolm,
>
> > I traced the problem and submitted the patch, see details at
> >http://code.djangoproject.com/ticket/4650
> > I'm not completely sure about the logic of signals though, the change
> > may affect some middleware depending on it.
>
> Thanks, Ilya. I'd gotten that far, too. Unfortunately, though, it isn't
> quite that easy. Well, it is that easy formod_python, however for WSGI
> compliance, we can't do that (since the WSGI handler returns an
> iterable).
>
> There are a few possibilities I've been bouncing around, but they all
> have downsides: introducing greater coupling between templates, HTTP and
> database so that we know when rendering stops (which will make it
> possible to behave similarly to the modpython case) or making WSGI
> return a single item iterable as recommended in PEP 333 for performance
> (downside is that the greater part of the memory savings are lost).
Sorry, showing my ignorance here. Are you saying that Django can
currently return to the WSGI adapter for the web server a Python
string in some cases?
Looking at the submitted patch it almost seems that that is possible
in some cases, otherwise I don't understand the need for the check:
197 if isinstance(self._response, basestring):
198 return chain([self._response],
IterConsumedSignal)
I only ask as returning a string means that the WSGI adapter would
treat it as an array of single character strings and by the WSGI
specification the WSGI adapter is required to write each character out
one at a time and perform a flush between each character. If doing
this in Apache this would result in absolutely dreadful performance.
As it stands, this patch would actually change the behaviour of a WSGI
adapter in that the string would then be written out in one go and not
one character at a time as it would if just the string were passed
through. Another issue with this check is that it checks against
'basestring' whereas WSGI is only supposed to be given 'string'
objects. The check would allow through 'unicode' string objects.
Also, I am presuming 'chain' comes from itertools but don't see that
module being imported. Nor is it prefixed by the module name anyway.
BTW, why does one need to be using chain of iterables anyway. The WSGI
specification requires that a WSGI adapter call close() on the
iterable when it is done. Ie., quoting WSGI specification:
"""If the iterable returned by the application has a close() method,
the server or gateway must call that method upon completion of the
current request, whether the request was completed normally, or
terminated early due to an error. (This is to support resource release
by the application. This protocol is intended to complement PEP 325's
generator support, and other common iterables with close() methods."""
Thus, it wasn't necessary to introduce IterConsumedSignal at all.
Instead, if I understand what you are trying to do. The
ResponseWrapper could have provided its own close() method which
called response close() if it existed as well as call:
dispatcher.send(signal=signals.request_finished)
> For portability reasons, supporting WSGI is very important, so any
> solution that only works with modpython is unfortunately not an option.
Why was the patch only suitable for mod_python? I admit I don't
understand fully the underlying problem you are trying to solve, but
as far as satisfying WSGI specification, it seemed to be going in the
right direction.
Graham
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~----------~----~----~----~------~----~------~--~---
