On 27/06/14 11:16, James Bennett wrote:
On Fri, Jun 27, 2014 at 3:12 AM, cercatrova2 <cercatrova2@gmail.com> wrote:--
"FastCGI support via the runfcgi management command will be removed in Django 1.9. Please deploy your project using WSGI."
Why does the documentation *persist* in confusing FastCGI with WSGI?
This does not confuse them (if it were confusing them, it would assume that FastCGI and WSGI are identical).
And it seems that the point made in the developer thread about deprecation being unwise was simply ignored and intentionally misunderstood (https://groups.google.com/forum/#!topic/django-developers/oGmD8LvLTPg "Deprecate FCGI support in Django 1.7").
I don't see anyone ignoring or intentionally misunderstanding in that thread.
The "runfcgi" command and its supporting code just implements a FastCGI<->WSGI bridge using flup. That's convenient for cases where FastCGI is the only deployment option, but it does come at a significant cost: flup appears to be abandonware, and the flup-based bridge has generated a lot of bugs and maintenance headaches. That cost was deemed the bigger issue, and so Django will no longer have a built-in FastCGI<->WSGI bridge based on flup.
This doesn't mean that Django can't be deployed using FastCGI, of course; it just means that someone else needs to provide the bridge from FastCGI to WSGI, because going forward Django will only support speaking WSGI, and will not include its own bridge to let it pretend to speak FastCGI or other gateway protocols. And in that thread several people showed interest in starting and maintaining a third-party package to provide that bridge. If FastCGI is a requirement for you, your best course is likely to follow up on that effort.
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscribe@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAL13Cg_sXKbHmwvp-JnihBqGGwq3wxoB8zZB1behdcQ%3DpPTB7w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Come now. When you say "FastCGI support via the runfcgi management command will be removed in Django 1.9. Please deploy your project using WSGI." it implies that they are mutually exclusive. They are not. I'm using FastCGI and I've deployed my project using WSGI.
It's like how the doc states "Although WSGI is the preferred deployment platform for Django, many people use shared hosting, on which protocols such as FastCGI, SCGI or AJP are the only viable options." Again the implication is that these things are mutually exclusive and again they are not.
If you were to say "FastCGI and flup support via the runfcgi management command will be removed in Django 1.9. You may of course continue to use FastCGI and flup or some other FastCGI-to-WSGI deployment technology independently at your own risk, or you may of course switch to another WSGI deployment technology." then IMHO it would make more sense.
Yes I noticed the interest in forking flup in the thread. I'll check it out.
Thanks for responding!
No comments:
Post a Comment