Re: Deprecate FCGI support in Django 1.7

[Some Developer]

On 19/07/13 01:31, Curtis Maloney wrote:

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?

I agree it's valuable to have, as many have said [and I believe all have
agreed] but to keep it in core is unmaintainable.

And by "help", it could just be as much as feature requests,
documentation, or testing [always testing! :)]

--
Curtis Maloney


Post a link to a Github repo for the project and I'll watch it. I'm not 
sure how much time I'd be able to contribute to it but I'll certainly 
help where I can.


--
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.

Re: Deprecate FCGI support in Django 1.7

[Curtis Maloney]

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?

I agree it's valuable to have, as many have said [and I believe all have
agreed] but to keep it in core is unmaintainable.

And by "help", it could just be as much as feature requests, documentation,
or testing [always testing! :)]

--
Curtis Maloney



On 19 July 2013 08:53, Javier Guerra Giraldez  wrote:

> On Thu, Jul 18, 2013 at 5:30 PM, Juan Luis Boya  wrote:
> > uWSGI + FastCGI: We should have nice docs about this.
>
>
> as others have previously said, uWSGI isn't viable for everybody.  is
> there any other pure-python fcgi-wsgi server with reasonable
> performance?
>
> 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.
>
>
> --
> Javier
>
> --
> 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.
>
>
>

-- 
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.

Re: Deprecate FCGI support in Django 1.7

[Javier Guerra Giraldez]

On Thu, Jul 18, 2013 at 5:30 PM, Juan Luis Boya  wrote:
> uWSGI + FastCGI: We should have nice docs about this.


as others have previously said, uWSGI isn't viable for everybody.  is
there any other pure-python fcgi-wsgi server with reasonable
performance?

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.


--
Javier

-- 
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.

Re: Deprecate FCGI support in Django 1.7

[Juan Luis Boya]

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.