I'm against deprecating FastCGI at all because it's the only cross platform, language independent, minimally scalable standard for deploying web applications in web servers (apart from HTTP proxy).
WSGI may be nice to Python developers, but the world doesn't end after Python. Not all web servers support WSGI nor many people will choose to deploy a Django application if he or she needs another web server for that task. (Yes, big applications may require their own physical or virtual server, but that's not the case for everyone.) Fulfilling a standard like FastCGI is a must. Also, FastCGI is **not that terrible**: You choose a prefix and tell the web server to redirect requests to the FastCGI server. Those are the basics. There are issues in some servers which make you have to configure rewrites if you want to serve static files from the same prefix but those are not real issues of FastCGI. On the other hand, flup is dead in many ways, but I think uWSGI with FastCGI may be a better alternative. We wouldn't need to worry about FastCGI ourselves, have more features and have no change in our infrastructure (uWSGI uses WSGI to communicate with the web application independently of the technology it uses to communicate with the web server). tl;dr: FastCGI: We have to support it. runfcgi + flup: Deprecating it may be a good decision. uWSGI + FastCGI: We should have nice docs about this. -- 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. For more options, visit https://groups.google.com/groups/opt_out.
