Certainly the implementation of the patch is not ideal (by accessing private attributes on HttpResponse), which is why I brought it up for discussion before going any further.
I do feel that there is a real benefit and even requirement in some cases to supporting streaming HttpResponse objects. If there was no streaming output, why would we accept generators (or anything other than string) as the content to HttpResponse at all? It would be easier to simply require content to be passed in as text and leave it to the developer to consume any generator before instantiating a HttpResponse object. If there was no streaming output, I don't see a good alternative when there's a need to return a large amount of dynamic content (e.g. CSV export) in response to an HTTP request. Even if users were to subclass HttpResponse on their own, won't they run into the same problem with 3rd party middleware (and even standard Django middleware at present) which ignores the fact that generators can be passed to HttpResponse as content? The other alternative I can think of is even less appealing - to trigger some scheduled offline processing through a web request and notify the user when it's ready to download as static media. The streaming HttpResponse functionality was initially favoured by Adrian when Ivan introduced it. It would be a shame to "just say no" to it, now. Is it really so bad to add a public attribute on HttpResponse that indicates whether or not the content is a static string or a generator, and have the Django standard middleware (especially any that are enabled by default) be aware of this and only enable features that require checking the entire content when a generator has not been used. Features such as: generating an ETag header, compressing the entire content in one hit instead of iteratively (is there a significant benefit to doing this in one hit?), and setting the Content-Length header? The default behaviour by "unaware" middleware is still to consume any content generator, so those middleware that are ignorant of streaming response will continue to work as they do now. But 3rd party developers who are aware of this can support it if they chose, or not, and Django should support it as best it can. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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-developers?hl=en -~----------~----~----~----~------~----~------~--~---
