On Jul 7, 3:56 am, Richard Shebora <sheb...@gmail.com> wrote: > This blog post by Graham Dumpleton could be listed > as additional reading for mod_wsgi implementations... > > http://blog.dscpl.com.au/2010/03/improved-wsgi-script-for-use-with.html > > It clears up what look like real problems on the surface, but are really > normal when you understand the process better.
No, it isn't that simple unfortunately. In talks I have had with core developers there are concerns from a number of areas over what that alternate script was doing. These are: 1. What really is the problem being solved? In respect of import ordering and/or multithreading issues, is this script just covering up for fact that people using Django aren't following the documentation and are therefore doing something wrong to cause their problems 2. By following what the Django development server does, then you preload bits of code which would never actually be used in a production setting and thus are increasing the size of Django process unnecessarily. 3. That there is a preference for lazy loading on basis that again avoid loading application code you don't need to. In respect of (1), what is really needed is a small example, with recipe of how to replicate problem reliably, for issues that script solves that are encountered when using standard WSGI recipe. So far no one has been able to supply that, usually because by the time they solve their problem by using this alternate WSGI script, they cant be bothered help work out the underlying reason as to why standard recipe isn't working. In respect of (2) and (3), is the memory increase really significant enough that this is a concern. Irrespective of (1) and whether it is a user problem, there certainly are issues to be resolved. For example, the fact that 'python manage.py runserver', 'django-admin.py runserver' and standard WSGIHandler recipe all set up the environment differently. I also challenge the idea that lazy loading is a good idea. The problem with lazy loading is that it forces a delay on to first request that needs to load the code. In a production hosting environment this may be undesirable. So, a lot more investigation and discussion is going to be needed on this. Graham > Thanks, > Richard Shebora > > On Tue, Jul 6, 2010 at 2:56 AM, Henrik Genssen > <henrik.gens...@miadi.net>wrote: > > > > > can we please add a hint to the docs here: > >http://docs.djangoproject.com/en/dev/howto/deployment/modwsgi/ > > > for: > > > WSGIPassAuthorization on > > > or one will never get HTTP_AUTHORIZATION in request.META > > > regards > > > Henrik > > > Henrik Genssen > > > h...@miadi.net > > Tel. 0451/6195650 > > Fax. 0451/6195655 > > > miadi GmbH > > Geschäftsführer: Henrik Genssen > > Sitz der Gesellschaft: Beckergrube 2, 23552 Lübeck > > Amtsgericht Lübeck HRB 10223, USt-IdNr DE > > Lieferungen und Leistungen erfolgen ausschließlich auf Grundlage unserer > > allgemeinen Geschäftsbedingungen > > > -- > > You received this message because you are subscribed to the Google Groups > > "Django users" group. > > To post to this group, send email to django-us...@googlegroups.com. > > To unsubscribe from this group, send email to > > django-users+unsubscr...@googlegroups.com<django-users%2bunsubscr...@google > > groups.com> > > . > > For more options, visit this group at > >http://groups.google.com/group/django-users?hl=en. -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
