Hello Gustavo, On 04/11/2013 08:31 AM, Gustavo Narea wrote: > In the interest of finding a resolution to Ticket #12091 > <https://code.djangoproject.com/ticket/12091>, a 3-year-old ticket, I > wanted to bring this issue to your attention. > > I think that Django should have built-in support for running WSGI > applications from inside views. (NB: I really mean running WSGI apps > from inside Django views -- I'm not talking about using a WSGI > middleware that routes requests to your Django project or another WSGI > application.) > > If you're able to embed WSGI applications in your Django project, you'd > be able to do many things. For example: > > * Control access to static files, while still letting your Web server > do the file transfer: http://pythonhosted.org/xsendfile/ > * Re-use your Django-based authentication in other applications, even > applications not written in Python. For example, if your Django site > runs at "/" and your Wordpress blog and Trac instance live at > "/blog/" and "/tickets/", respectively, your users would only have > to log in once if your Django site proxies requests to Wordpress and > Trac. Here's how I've integrate them in the > past: https://bitbucket.org/Gustavo/weesgo/ > and http://gustavonarea.net/files/talks/europython2010/all-materials.zip > * Alter the response returned by another web application or web site, > using HttpResponse objects. > > It basically comes down to being able to integrate other applications > and websites, and then filter the requests they get and/or the responses > they return -- Using Django request and response objects.
This does seem like a useful feature for some situations, though it's not a feature that I've seen much demand for. > I decided to reimplement the patch I created 3 years ago in a separate > project (twod.wsgi > <http://pythonhosted.org/twod.wsgi/manual/embedded-apps.html>), which > means that it's possible to do this without changing Django. However, it > doesn't support embedding Django projects because of Django's use of > global data (DJANGO_SETTINGS_MODULE and django.conf.settings), which I > think can only be solved by introducing thread locals in django.conf. At > the moment, the only way to accomplish this would be by proxying the > second Django site with inter-process communication (e.g., CGI, FastCGI > or HTTP). If I understand correctly, this latter limitation is not something that would be solved by integrating twod.wsgi into Django core. Are there any issues or problems with twod.wsgi that would be solved by integrating it into core? > So, do you agree that Django should have built-in support for running > WSGI applications from inside views? I'm inclined to agree with Aymeric's position on the ticket: this is a useful feature for some scenarios, but it works just fine as a standalone project, and I just don't see enough demand for it to justify adding the maintenance burden for it to core. Carl -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
