As much as I recognise FastCGI is pretty much a dead technology in the Python world, for people stuck with cPanel sites like HostGator, it still appears to be, pretty much, the only option.And installing uWSGI there is simply not an option there.So unless there's a pure python FastCGI -> WSGI library built that supports Django, we're just closing the door on this avenue...[I say this despite my personal loathing of HostGator... :)]
I'm not arguing that FastCGI is a good option, just that it's prevalent. And if we're going to stop supporting it, we need to be aware of who we're cutting off.
If you're suggesting to move the FastCGI code into a separate app: +1
--
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+unsubscribe@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.
What about SCGI and AJP support? Is that going?
- Django's core developers don't use FCGI — at least, I don't know any active core dev who does.
That makes FCGI a dead end. At some point we'll have to pull the plug. Right now seems early.
Also, if we move it outside of django-core we can send a good signal that FCGI in Django is basically "Use at your own risk" (which it is already if you ask me).
--
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-develop...@googlegroups.com.
To post to this group, send email to django-d...@googlegroups.com.
i think several people like to use gunicorn for http-wsgi, if it (or
something similar: flask? wep.py?, werkzeug?) supports fcgi, it could
be the recommended fcgi solution.
For those who are keen to keep support for FastCGI, would you be interested in helping me develop/maintain a Pure Python FastCGI->WSGI(Django-specific) publisher package?
Hi,
I'd like to get rid of everything FCGI-specific in Django sooner or later (rather sooner). Flup isn't maintained since a long time and there is no ticket tracker to report stuff. Graham pointed out that if someone wants to use FCGI they can use http://uwsgi-docs.readthedocs.org/en/latest/Options.html#fastcgi-socket which doesn't even require flup, which sounds like a good compromise to me. I'd need some help for the docs from some uWSGI users, since I have no idea about it ;)
Thoughts, objections?
Cheers,
Florian
For those who are keen to keep support for FastCGI, would you be interested in helping me develop/maintain a Pure Python FastCGI->WSGI(Django-specific) publisher package?
That exists and it's called flup. The code base is relatively small. What about simply forking it to something like flup2 and fixing the issues?
--
If you really want to get down and dirty with raw protocols have you
considered an implementation that used epoll or kqueue for the
networking? Combined with nginx as the front end HTTP server it should
(theoretically) result in a huge increase in performance.
Basing the work on one of the Python async networking libraries
(Twisted, Eventlet, gevent etc) should result in better performance and
might well make FastCGI competitive with uWSGI and WSGI again. I really
think that flup is the bottleneck when it comes to using FastCGI with
Django. Having said that I haven't had a chance to look at the Django
side of the code yet so there might be some optimisations that are
possible there as well.
--
On 20/07/2013 14:02, Curtis Maloney wrote:
I'm more or less building atop flup as it is, however I plan to shed
anything not related to FastCGI.
For me it's a chance to get down and dirty with raw protocols again... I
do agree there is a shorter path to just applying Django's "fixes" to a
fork of flup.
If you really want to get down and dirty with raw protocols have you considered an implementation that used epoll or kqueue for the networking? Combined with nginx as the front end HTTP server it should (theoretically) result in a huge increase in performance.
Basing the work on one of the Python async networking libraries (Twisted, Eventlet, gevent etc) should result in better performance and might well make FastCGI competitive with uWSGI and WSGI again. I really think that flup is the bottleneck when it comes to using FastCGI with Django. Having said that I haven't had a chance to look at the Django side of the code yet so there might be some optimisations that are possible there as well.
Juan, technically Django isn't a server at all...
whether it's sync, async, multi-threaded, multi-process, or a mix of any of them is up to the wsgi publisher used.
--
P.S What's a BDFL? :)
--
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+unsubscribe@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Is there a specific reason to call this "django-fastcgi"? I think it should most likely be a generic wsgi to fastcgi binding, right? Or is this project mainly the django management commands?
To unsubscribe from this group and stop receiving emails from it, send an email to django-develop...@googlegroups.com.
To post to this group, send email to django-d...@googlegroups.com.
I would recommand to remove FastCGI.
That's the thing i love with the Python Community. Remove depracted or obsolete things.The thing is, there are way more important things to do, than supporting a 'depracted' way to deploy. And it's really not that hard to get mod_wsgi with a httpd running.You could strip that down so easily and compile it, even on CentOS.
Maybe it's better to improve the Docs about Apache2 / nginx / HAProxy deployment with mod_wsgi than supporting FCGI.I mean some things like that:I think that these things are really important. Howto get from development to Production, with security.(btw. the talk is from 2011 and some things aren't up 2 date, like the pgpool single point of failure thing, etc. today you could really well deploy a good enviroment or 2 or more servers where you don't have any single point of failure where you don't need to add any extra line of code. okai maybe you need to find a good way to hold cookies in a good memory based database, that you could share them between machines, but that is the only thing you should care about, since that is the only you shouldn't hold in your legacy database.)