Re: Deprecate FCGI support in Django 1.7

[Javier Guerra Giraldez]

On Tue, Aug 6, 2013 at 9:40 AM, Andre Terra  wrote:
> Assuming a UNIX environment. In Windowsland, nginx is still one of the best
> alternatives.


I meant use those _behind_ NginX.  neither is really good as an
external-facing HTTP process.

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

[Andre Terra]

On Tue, Aug 6, 2013 at 10:18 AM, Javier Guerra Giraldez
wrote:

> On Tue, Aug 6, 2013 at 6:28 AM, VernonCole  wrote:
> > I had come the the conclusion that FastCGI was the only way
>
>
> behind NginX, the best two options seem to be uWSGI and gunicorn.
> personally, I like uWSGI, but both are quite performant and
> low-resource.


Assuming a UNIX environment. In Windowsland, nginx is still one of the best
alternatives.


Cheers,
AT

-- 
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 Tue, Aug 6, 2013 at 6:28 AM, VernonCole  wrote:
> I had come the the conclusion that FastCGI was the only way


behind NginX, the best two options seem to be uWSGI and gunicorn.
personally, I like uWSGI, but both are quite performant and
low-resource.

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

[VernonCole]

Let me second the need for a good "How To" document on deployment.  As a 
neophyte django user I suddenly felt very lost last week. After several 
months of development, the ADO interface to the Microsoft SQL server from 
Linux is working (it still needs some tuning, but the data does go in and 
out using runserver) and it is now time to deploy.  The boss requested an 
Nginx server, so I started searching the web for how to do it.  I had come 
the the conclusion that FastCGI was the only way that I could deploy and 
was planning on starting that this morning, until I read this thread.  Now 
I know that I was about to start down an obsolescent path. A "How To" in 
the official documentation would have prevented this false start.

Does anyone know of an existing cookbook that I can refer to as a starting 
point? Or should I be making accurate records of my work with a view to 
contributing a new document?
--
Vernon Cole
 

On Saturday, July 20, 2013 5:32:44 AM UTC-6, Christian Schmitt wrote:
>
> 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:
>
> > 
> http://ontwik.com/python/django-deployment-workshop-by-jacob-kaplan-moss/
>
> 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.)
>
> Am Sonntag, 14. Juli 2013 21:17:00 UTC+2 schrieb Florian Apolloner:
>>
>> 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-socketwhich 
>> 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
>>
>

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

[Tim Graham]

Is there a consensus on the project that'll be created to handle this 
outside of Django? Would be nice to have something to point people to when 
closing Trac tickets for FastCGI.

On Wednesday, July 24, 2013 5:56:45 AM UTC-4, Tom Evans wrote:
>
> On Sun, Jul 21, 2013 at 8:28 AM, Some Developer 
>  wrote: 
> > On 21/07/2013 05:08, Curtis Maloney wrote: 
> >> 
> >> I wasn't aware there was a particular performance issue, but I'll 
> >> certainly keep it in mind. 
> > 
> > 
> > Take a look at this: 
> > 
> > http://www.peterbe.com/plog/fcgi-vs-gunicorn-vs-uwsgi 
> > 
> > I've probably already said it but if you want some help with this 
> project 
> > I'd be interested. 
>
> Did you notice that the first thing that anyone does when benchmarking 
> HTTP servers is that they reduce the work being done by the server so 
> that it is trivial. That link explains it best, if you throw away 
> everything that Django provides and simply use it to render a static 
> string, then uWSGI is faster than gunicorn, which is faster than FCGI. 
> If you leave any of it enabled however, they all benchmark at 
> precisely the same speed. 
>
> So, if your django website does not use sessions nor databases nor 
> templates, then sure, you get a huge performance benefit from fiddling 
> around with serving mechanisms. 
>
> Cheers 
>
> Tom 
>

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

[Tom Evans]

On Sun, Jul 21, 2013 at 8:28 AM, Some Developer
 wrote:
> On 21/07/2013 05:08, Curtis Maloney wrote:
>>
>> I wasn't aware there was a particular performance issue, but I'll
>> certainly keep it in mind.
>
>
> Take a look at this:
>
> http://www.peterbe.com/plog/fcgi-vs-gunicorn-vs-uwsgi
>
> I've probably already said it but if you want some help with this project
> I'd be interested.

Did you notice that the first thing that anyone does when benchmarking
HTTP servers is that they reduce the work being done by the server so
that it is trivial. That link explains it best, if you throw away
everything that Django provides and simply use it to render a static
string, then uWSGI is faster than gunicorn, which is faster than FCGI.
If you leave any of it enabled however, they all benchmark at
precisely the same speed.

So, if your django website does not use sessions nor databases nor
templates, then sure, you get a huge performance benefit from fiddling
around with serving mechanisms.

Cheers

Tom

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

Well, mostly to indicate it's primary focus is on providing a FastCGI
server for Django.

I'm quite happy to keep it app agnostic, and be a general FastCGI->WSGI
publisher...


On 24 July 2013 15:04, Joe Tennies  wrote:

> 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?
> On Jul 22, 2013 8:07 PM, "Curtis Maloney" 
> wrote:
>
>> Well, having started looking over the flup source, I can see a lot of
>> useful code to crib, as well as a few critical path bits that can be
>> optimised [without even reducing readability!]
>>
>> So, if you feel like helping out with django-fastcgi ... I'm happy for
>> the help :)
>>
>> --
>> Curtis
>>
>>
>>
>> On 23 July 2013 03:25, Some Developer  wrote:
>>
>>> On 22/07/13 10:00, Russell Keith-Magee wrote:
>>>
 The hope is to start accelerating the release cycle slightly; however,
 this also depends on someone actually doing the work :-)

>>>
>>> Sounds good. I'd love to start helping with Django myself but I feel a
>>> bit lost when it comes to useful things to do. Maybe I'll start checking
>>> out the bug tracker and seeing what I can do there.
>>>
>>>
>>> --
>>> 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
>>> .
>>>
>>>
>>>
>>  --
>> 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.
>
>
>

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

[Joe Tennies]

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?
On Jul 22, 2013 8:07 PM, "Curtis Maloney" 
wrote:

> Well, having started looking over the flup source, I can see a lot of
> useful code to crib, as well as a few critical path bits that can be
> optimised [without even reducing readability!]
>
> So, if you feel like helping out with django-fastcgi ... I'm happy for the
> help :)
>
> --
> Curtis
>
>
>
> On 23 July 2013 03:25, Some Developer  wrote:
>
>> On 22/07/13 10:00, Russell Keith-Magee wrote:
>>
>>> The hope is to start accelerating the release cycle slightly; however,
>>> this also depends on someone actually doing the work :-)
>>>
>>
>> Sounds good. I'd love to start helping with Django myself but I feel a
>> bit lost when it comes to useful things to do. Maybe I'll start checking
>> out the bug tracker and seeing what I can do there.
>>
>>
>> --
>> 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
>> .
>>
>>
>>
>  --
> 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

[Tim Graham]

Here's a ticket  and pull 
request  for the deprecation.

On Tuesday, July 23, 2013 1:19:28 AM UTC-4, Some Developer wrote:
>
> On 23/07/13 02:07, Curtis Maloney wrote: 
> > Well, having started looking over the flup source, I can see a lot of 
> > useful code to crib, as well as a few critical path bits that can be 
> > optimised [without even reducing readability!] 
> > 
> > So, if you feel like helping out with django-fastcgi ... I'm happy for 
> > the help :) 
> > 
> > -- 
> > Curtis 
>
> Fork it and upload it to Github and then we can see where we stand. 
> Github probably has the best chance of getting people involved with it. 
>
> But yeah I'm available to help. Although I'm back at work next week so 
> my time will be somewhat more limited than it is at the moment. 
>
>

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

[Some Developer]

On 23/07/13 02:07, Curtis Maloney wrote:

Well, having started looking over the flup source, I can see a lot of
useful code to crib, as well as a few critical path bits that can be
optimised [without even reducing readability!]

So, if you feel like helping out with django-fastcgi ... I'm happy for
the help :)

--
Curtis


Fork it and upload it to Github and then we can see where we stand. 
Github probably has the best chance of getting people involved with it.


But yeah I'm available to help. Although I'm back at work next week so 
my time will be somewhat more limited than it is at the moment.


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

Well, having started looking over the flup source, I can see a lot of
useful code to crib, as well as a few critical path bits that can be
optimised [without even reducing readability!]

So, if you feel like helping out with django-fastcgi ... I'm happy for the
help :)

--
Curtis



On 23 July 2013 03:25, Some Developer  wrote:

> On 22/07/13 10:00, Russell Keith-Magee wrote:
>
>> The hope is to start accelerating the release cycle slightly; however,
>> this also depends on someone actually doing the work :-)
>>
>
> Sounds good. I'd love to start helping with Django myself but I feel a bit
> lost when it comes to useful things to do. Maybe I'll start checking out
> the bug tracker and seeing what I can do there.
>
>
> --
> 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
> .
>
>
>

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

[Some Developer]

On 22/07/13 10:00, Russell Keith-Magee wrote:

The hope is to start accelerating the release cycle slightly; however,
this also depends on someone actually doing the work :-)


Sounds good. I'd love to start helping with Django myself but I feel a 
bit lost when it comes to useful things to do. Maybe I'll start checking 
out the bug tracker and seeing what I can do there.


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

[Aymeric Augustin]

> To anyone else reading this thread who is still wanting FastCGI I am willing 
> to help with a third party solution if something is going to come together. 
> Based on the normal Django release cycle I'd expect 1.7 to be out in either 
> Q4 this year or Q1 next year so something needs to be done by then 
> (preferably including testing in production - something which I can help 
> with).

FastCGI will be pending deprecation in Django 1.7 and deprecated in Django 1.8. 
It wont' be removed until Django 1.9. You actually need a solution by 2015!

> P.S What's a BDFL? :)

It's an acronym for "Benevolent Dictator for Life". See 
https://en.wikipedia.org/wiki/Benevolent_Dictator_for_Life for details.

-- 
Aymeric.

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

[Russell Keith-Magee]

On Mon, Jul 22, 2013 at 4:48 PM, Some Developer
wrote:

> On 22/07/13 05:47, Russell Keith-Magee wrote:
>
>> Based on the feedback from this thread (and the fact that multiple core
>> devs, including a BDFL have weighed in), I think it's safe to say that
>> the decision has been made. The only question at this point is how long
>> it takes before someone commits the changeset that implements the start
>> of the deprecation process.
>>
>> Yours,
>> Russ Magee %-)
>>
>
> Thanks. Its always better to know that a definitive decision has been made.
>
> I guess now we can start looking into third party alternatives.
>
> To anyone else reading this thread who is still wanting FastCGI I am
> willing to help with a third party solution if something is going to come
> together. Based on the normal Django release cycle I'd expect 1.7 to be out
> in either Q4 this year or Q1 next year so something needs to be done by
> then (preferably including testing in production - something which I can
> help with).
>

The hope is to start accelerating the release cycle slightly; however, this
also depends on someone actually doing the work :-)


> P.S What's a BDFL? :)
>
> https://en.wikipedia.org/wiki/Benevolent_Dictator_for_Life

Yours,
Russ Magee %-)

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

[Some Developer]

On 22/07/13 05:47, Russell Keith-Magee wrote:

Based on the feedback from this thread (and the fact that multiple core
devs, including a BDFL have weighed in), I think it's safe to say that
the decision has been made. The only question at this point is how long
it takes before someone commits the changeset that implements the start
of the deprecation process.

Yours,
Russ Magee %-)


Thanks. Its always better to know that a definitive decision has been made.

I guess now we can start looking into third party alternatives.

To anyone else reading this thread who is still wanting FastCGI I am 
willing to help with a third party solution if something is going to 
come together. Based on the normal Django release cycle I'd expect 1.7 
to be out in either Q4 this year or Q1 next year so something needs to 
be done by then (preferably including testing in production - something 
which I can help with).


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

[Russell Keith-Magee]

On Mon, Jul 22, 2013 at 12:21 PM, Some Developer
wrote:

> On 14/07/13 20:17, Florian Apolloner wrote:
>
>> 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
>>
>
> So has this decision been made yet? If it has myself and others can start
> coming up with solutions for those who want FastCGI. If it hasen't then we
> can avoid wasting time on something that is going to be a non-issue.
>
> The sooner that work is started before 1.7 though means that it might not
> actually be a problem for users since FastCGI will still work.


Based on the feedback from this thread (and the fact that multiple core
devs, including a BDFL have weighed in), I think it's safe to say that the
decision has been made. The only question at this point is how long it
takes before someone commits the changeset that implements the start of the
deprecation process.

Yours,
Russ Magee %-)

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

[Some Developer]

On 14/07/13 20:17, Florian Apolloner wrote:

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


So has this decision been made yet? If it has myself and others can 
start coming up with solutions for those who want FastCGI. If it hasen't 
then we can avoid wasting time on something that is going to be a non-issue.


The sooner that work is started before 1.7 though means that it might 
not actually be a problem for users since FastCGI will still work.


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

My understanding was Django is a WSGI application, and as such its role is
to process requests handed to it.  It isn't the server as such.

It's the role of a WSGI publisher to accept requests and pass them on to an
appropriate handler.  So, uWSGI, gunicorn, flup and mod_wsgi as the
Publishers we most often hear of, and it's generally their place to
implement the fork/thread/greenlet model used.



On 22 July 2013 02:39, Juan Luis Boya  wrote:

>
> Juan, technically Django isn't a server at all...
>>
>
> Django is a web application framework whose operation consists on waiting
> for HTTP requests from the network (encapsulated with WSGI) and replying
> each one of them with a HTTP response. Call it what you want.
>
>
>> whether it's sync, async, multi-threaded, multi-process, or a mix of any
>> of them is up to the wsgi publisher used.
>>
>
> This is what I understand with 'asynchronous' and 'synchronous' servers:
>
> * A synchronous server attends only one client connection at a time for
> each worker thread. Concurrency is achieved with operating system
> mechanisms like threads and processes.
> * An asynchronous server may be attending many client connections at a
> time for each worker thread. Concurrency is achieved within the thread
> using an application specific dispatcher. In an asynchronous server, there
> is only one blocking call accepted, which selects events from all
> connections. Typically this call is select(), epoll() or kqueue() depending
> on the system. **Other blocking calls must not be used because they would
> block the entire server until they return, preventing all available
> processing for other connections and thus killing server performance**.
> Therefore, asynchronous programming impose additional restrictions to the
> programmer, like:
>* Do not read or write files yourself, cause read() and write() are
> blocking by default. You must pass those operations through the dispatcher.
>* All database operations must pass through the dispatcher too. You
> can't block the thread until a SQL statement ends its execution.
>* All additional HTTP requests (like those to external APIs) must pass
> through the dispatcher too in order to not block the server until they are
> replied.
> and so on...
>
> There are also mixed approaches, i.e. an asynchronous load balancer which
> delivers new connections to synchronous worker threads or processes using
> IPC mechanisms.
>
> Since most (if not all) Django applications rely on blocking operations
> like those stated before, trying to make Django an asynchronous web
> platform expecting a huge performance improvement is a wrong idea. Putting
> that apart, the asynchronous load balancer (which can create and delete
> threads/processes depending on the server load) is not a bad idea.
>
> --
> 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 Sun, Jul 21, 2013 at 11:39 AM, Juan Luis Boya  wrote:
> * An asynchronous server may be attending many client connections at a time
> for each worker thread. Concurrency is achieved within the thread using an
> application specific dispatcher. In an asynchronous server, there is only
> one blocking call accepted, which selects events from all connections.
> Typically this call is select(), epoll() or kqueue() depending on the
> system. **Other blocking calls must not be used because they would block the
> entire server until they return, preventing all available processing for
> other connections and thus killing server performance**. Therefore,
> asynchronous programming impose additional restrictions to the programmer,
> like:


this is mostly right; but python, being a high level language, leaves
a lot of space to change things.

greenlets, gevents and eventles take advantage of that, monkepatching
several crucial parts of the standard library, making it
asynchronous-friendly.  in the end, reasonably good code becomes
mostly good for an asynchronous sever.

That's what happens when you run use gunicorn to run Django, which is
a very popular option (and isn't bad at all).  An asynchronous
FCGI-WSGI tool could have a similar performance without any changes in
Django.

in fact, i still think that maybe (just maybe) the easiest would be to
replace the HTTP parser in gunicorn with an FCGI one, keeping all the
asynchronous structure and WSGI handling code.

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

> Juan, technically Django isn't a server at all...
>

Django is a web application framework whose operation consists on waiting 
for HTTP requests from the network (encapsulated with WSGI) and replying 
each one of them with a HTTP response. Call it what you want.
 

> whether it's sync, async, multi-threaded, multi-process, or a mix of any 
> of them is up to the wsgi publisher used.
>

This is what I understand with 'asynchronous' and 'synchronous' servers: 

* A synchronous server attends only one client connection at a time for 
each worker thread. Concurrency is achieved with operating system 
mechanisms like threads and processes.
* An asynchronous server may be attending many client connections at a time 
for each worker thread. Concurrency is achieved within the thread using an 
application specific dispatcher. In an asynchronous server, there is only 
one blocking call accepted, which selects events from all connections. 
Typically this call is select(), epoll() or kqueue() depending on the 
system. **Other blocking calls must not be used because they would block 
the entire server until they return, preventing all available processing 
for other connections and thus killing server performance**. Therefore, 
asynchronous programming impose additional restrictions to the programmer, 
like:
   * Do not read or write files yourself, cause read() and write() are 
blocking by default. You must pass those operations through the dispatcher.
   * All database operations must pass through the dispatcher too. You 
can't block the thread until a SQL statement ends its execution.
   * All additional HTTP requests (like those to external APIs) must pass 
through the dispatcher too in order to not block the server until they are 
replied.
and so on...

There are also mixed approaches, i.e. an asynchronous load balancer which 
delivers new connections to synchronous worker threads or processes using 
IPC mechanisms.

Since most (if not all) Django applications rely on blocking operations 
like those stated before, trying to make Django an asynchronous web 
platform expecting a huge performance improvement is a wrong idea. Putting 
that apart, the asynchronous load balancer (which can create and delete 
threads/processes depending on the server load) is not a bad idea.

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

[Some Developer]

On 21/07/2013 05:08, Curtis Maloney wrote:

I wasn't aware there was a particular performance issue, but I'll
certainly keep it in mind.


Take a look at this:

http://www.peterbe.com/plog/fcgi-vs-gunicorn-vs-uwsgi

I've probably already said it but if you want some help with this 
project I'd be interested.


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

On 21 July 2013 02:30, Some Developer  wrote:

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

Well, that remains to be seen... it's early days yet, but I hope to be able
to support various work models.



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


I wasn't aware there was a particular performance issue, but I'll certainly
keep it in mind.

Mostly, I was hoping to raise a new project to bear the burden of
maintenance, instead of Django core.  From what I've seen of late there's
various parts of the code which could be simplified if core assumes it's
only ever a WSGI app to be published.

--
Curtis

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

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.

Take, for example, gunicorn, which can be any of the above, with options to
plug in others when they're thought up.

--
Curtis



On 21 July 2013 02:54, Juan Luis Boya  wrote:

>
> 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.
>>
>>
> AFAIK Django is not an asynchronous server, so each thread or process will
> handle only one connection at a time. That renders the asynchronous
> approach near useless.
>
> Correct me if I'm wrong.
>
> --
> 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

[Juan Luis Boya]

> 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. 
>
>  
AFAIK Django is not an asynchronous server, so each thread or process will 
handle only one connection at a time. That renders the asynchronous 
approach near useless.

Correct me if I'm wrong.

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

[Christian Schmitt]

No FastCGI isn't a bad protocol. But it's not recommand to deploy Python 
Application's with FastCGI. FastCGI is good for deploying PHP or even 
sometimes Golang (but here, the plain Webserver is better).
But! FastCGI is a low level protocol and WSGI tries to get rid of that.
Flup is just a server/middleware that makes a WSGI based Application to a 
SCGI/FCGI one. It's never recommand to use a low level api, when you don't 
have to.
Also people who deployed on FastCGI should change that behavior to 
mod_wsgi, and there are a shitload of hosters that already supporting 
mod_wsgi, so it's really not that easy to change your hoster.

Btw. the djangoproject also have a good list which lists some hosters:
https://code.djangoproject.com/wiki/DjangoFriendlyWebHosts

Am Samstag, 20. Juli 2013 13:56:07 UTC+2 schrieb Some Developer:
>
> On 20/07/13 12:32, Christian Schmitt wrote: 
> > 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. 
>
> The thing that people seem to be missing here is that FastCGI is not 
> obsolete. There is currently no other deployment technology that can 
> reasonably replace it for the people who make use of it (with the 
> possible exception of SCGI). 
>
> FastCGI is essential in environments where websites are hosted that use 
> different languages and frameworks. WSGI is Python only and therefore 
> would require two deployment methods based on technology used increasing 
> maintenance overhead and ultimately cost. 
>
> uWSGI is starting to get a few more plugins written for it for other 
> languages but it is still lacking somewhat (and when I have a couple of 
> days spare I may well work on adding some of what I need). 
>
> Nor is FastCGI obsolete. People in the technology field suffer from a 
> problem were old = bad when in fact old means stability which is crucial 
> for important production sites. Flup may well have issues and I would be 
> more than happy to work on fixing those issues but lets not mistake 
> problems with Flup as problems with FastCGI itself. Flup is an 
> implementation. FastCGI is a protocol and the protocol is just fine. 
>
>
>

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

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.

--
Curtis



On 19 July 2013 22:14, Juan Luis Boya  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?
>>
>
> 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?
>
> --
> 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

[Some Developer]

On 20/07/13 13:24, Christian Schmitt wrote:

No FastCGI isn't a bad protocol. But it's not recommand to deploy Python
Application's with FastCGI. FastCGI is good for deploying PHP or even
sometimes Golang (but here, the plain Webserver is better).
But! FastCGI is a low level protocol and WSGI tries to get rid of that.
Flup is just a server/middleware that makes a WSGI based Application to
a SCGI/FCGI one. It's never recommand to use a low level api, when you
don't have to.
Also people who deployed on FastCGI should change that behavior to
mod_wsgi, and there are a shitload of hosters that already supporting
mod_wsgi, so it's really not that easy to change your hoster.

Btw. the djangoproject also have a good list which lists some hosters:
https://code.djangoproject.com/wiki/DjangoFriendlyWebHosts


I think you have completely missed my point. The people I am talking 
about are the ones who maintain their own servers. Plus there are lots 
of languages out there than can be deployed using FastCGI (off the top 
of my head I know people use FastCGI for Haskell, Scheme, PHP, Go, Rust, 
Python, Perl, C, and C++).


Your argument about FastCGI being a low level protocol is a bit weak to 
be honest. Those using it know about the protocol and know how to work 
with it. mod_wsgi does not solve the problem I laid out in my previous 
post which is that it is better to have one deployment technology in use 
regardless of the language used. This is what makes FastCGI unique at 
the moment.


I'm longing for the day when uwsgi reaches the same level of adoption 
but it won't be for sometime yet.


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

[Some Developer]

On 20/07/13 12:32, Christian Schmitt wrote:

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.


The thing that people seem to be missing here is that FastCGI is not 
obsolete. There is currently no other deployment technology that can 
reasonably replace it for the people who make use of it (with the 
possible exception of SCGI).


FastCGI is essential in environments where websites are hosted that use 
different languages and frameworks. WSGI is Python only and therefore 
would require two deployment methods based on technology used increasing 
maintenance overhead and ultimately cost.


uWSGI is starting to get a few more plugins written for it for other 
languages but it is still lacking somewhat (and when I have a couple of 
days spare I may well work on adding some of what I need).


Nor is FastCGI obsolete. People in the technology field suffer from a 
problem were old = bad when in fact old means stability which is crucial 
for important production sites. Flup may well have issues and I would be 
more than happy to work on fixing those issues but lets not mistake 
problems with Flup as problems with FastCGI itself. Flup is an 
implementation. FastCGI is a protocol and the protocol is just fine.



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

[Christian Schmitt]

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:

> http://ontwik.com/python/django-deployment-workshop-by-jacob-kaplan-moss/

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

Am Sonntag, 14. Juli 2013 21:17:00 UTC+2 schrieb Florian Apolloner:
>
> 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-socketwhich 
> 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
>

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

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

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

On Friday, July 19, 2013 12:53:48 AM UTC+2, Javier Guerra wrote:

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

flask, webpy, werkzeug: all of those use flup. gunicorn is an HTTP server, 
unrelated AFAIK. 

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

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

Re: Deprecate FCGI support in Django 1.7

[Aymeric Augustin]

On 15 juil. 2013, at 23:45, Jacob Kaplan-Moss  wrote:

> Let's start FCGI (and the others) down the path to deprecation. If there's 
> truly a community that finds value in these things -- and frankly I think 
> that once they try modern options they'll quickly switch and never look back 
> -- then let them maintain the code.

OK, I'm convinced, let's do that!

-- 
Aymeric.


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

[Ramiro Morales]

On Mon, Jul 15, 2013 at 6:45 PM, Jacob Kaplan-Moss  wrote:
>
> Let's start FCGI (and the others) down the path to deprecation. If there's
> truly a community that finds value in these things -- and frankly I think
> that once they try modern options they'll quickly switch and never look back
> -- then let them maintain the code.

Coincidentally, Juan Luis Boya has just attached a [1]patch to ticket
#20751.

It includes an initial FastCGI testing infrastructure that could be of
help to the maintainers of any project that result of this discussion.

-- 
Ramiro Morales
@ramiromorales

1. 
https://code.djangoproject.com/attachment/ticket/20751/0001-socketumask-argument-for-runfcgi-tests.patch

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

[Jacob Kaplan-Moss]

On Mon, Jul 15, 2013 at 4:31 PM, Florian Apolloner wrote:

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

This, for me, is the key: anything that's not a WSGI container is basically
the wrong way to serve Django. Full stop. By continuing to include these
other weird protocols we're implying that they're fully supported when
they're actually totally not. Back in the day, we needed FCGI support
because the options for hosting Python stuff was super limited. Today,
there are a ton of options, even in the ultra-low-cost category.

Let's start FCGI (and the others) down the path to deprecation. If there's
truly a community that finds value in these things -- and frankly I think
that once they try modern options they'll quickly switch and never look
back -- then let them maintain the code.

Jacob

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

[Florian Apolloner]

On Monday, July 15, 2013 9:55:51 PM UTC+2, Aymeric Augustin wrote:
>
> - Django's core developers don't use FCGI — at least, I don't know any 
> active core dev who does. 
>

I do, but with a patched flup and a patched suexec and what else, so I am 
hardly a typical usecase; and I am in the process of moving the systems to 
a sane setup.
 

> That makes FCGI a dead end. At some point we'll have to pull the plug. 
> Right now seems early. 
>

The plug is pulled when it's removed from Django, deprecating doesn't mean 
right now. 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-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

[Florian Apolloner]

On Monday, July 15, 2013 6:20:45 PM UTC+2, Some Developer wrote:
>
> What about SCGI and AJP support? Is that going? 
>
Yes, it's either all or nothing.

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

[Some Developer]

On 15/07/2013 13:37, Florian Apolloner wrote:

On Monday, July 15, 2013 9:38:33 AM UTC+2, Some Developer wrote:

This would be a mistake in my opinion.


Based on what? Django would still support FCGI via flup like it does
now, we'd just get rid of the management commands you usually can't use
on shared hosting either way…


OK. Your initial post was somewhat confusing in that case.


I'd like to get rid of everything FCGI-specific in Django sooner or later 
(rather sooner).


The question is why? There is very little FastCGI boilerplate in Django 
as it is and what is there hasn't been touched for a number of years 
(the runfcgi management command file hasn't been touched for 6 years).


Why not just remove the documentation for FastCGI, SCGI and AJP and make 
it clear that WSGI is the only supported option for deploying Django 
applications but keep the legacy code available for those who already 
use it.


Developers then don't need to worry about breaking it since it is no 
longer supported and those that do use FastCGI, SCGI and AJP can submit 
patches to fix it if it ever does get broken. This also includes 
submitting patches to flup if it is still maintained or taking it over 
if it is not.


This way everyone wins.

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

[gilberto dos santos alves]

remember that on "shared hosts" we do not have option to use, explicity
http ports, like examples from [1]. we do not have root access, nor
http.conf access for apache2/root configs.

when we hare dedicated server it is easy run app with django.

on shared host, all config for running django fcgi is made using with user
ssh terminal, and with sftp/ftp (example filezilla), .htaccess files and
cpanel.

for install uwsgi we need c compiler, that we do not have on shared hosts.

It is more easy and less expensive for "first-time companies using web
apps" use shared hosts and only solution that i find is using fcgi.

if necessary additional work todo (installs, .htaccess, etc) it is not the
problem


[1] http://flask.pocoo.org/docs/deploying/fastcgi/?highlight=fcgi


2013/7/15 Some Developer 

> On 15/07/13 16:10, Florian Apolloner wrote:
>
>> On Monday, July 15, 2013 4:14:43 PM UTC+2, Jannis Leidel wrote:
>>
>> If you're suggesting to move the FastCGI code into a separate app: +1
>>
>>
>> I'd have just dropped it, but yes we can move it out; although someone
>> else will have to step up to continue maintaining it (if there is a need
>> to maintain it).
>>
>> Florian
>>
>
> What about SCGI and AJP support? Is that going?
>
> Seems silly to drop FastCGI which is probably the most popular of three
> and leave the other two intact. If you're going to drop something drop all
> three.
>
> At least then it is clear to users that WSGI is the only supported option
> in Django.
>
> Third parties can then maintain FastCGI, SCGI and AJP support (which I
> believe all come from flup anayway).
>
>
> --
> 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
> .
>
>
>


-- 
gilberto dos santos alves
+55.11.98646-5049
sao paulo - sp - brasil

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

[Some Developer]

On 15/07/13 16:10, Florian Apolloner wrote:

On Monday, July 15, 2013 4:14:43 PM UTC+2, Jannis Leidel wrote:

If you're suggesting to move the FastCGI code into a separate app: +1


I'd have just dropped it, but yes we can move it out; although someone
else will have to step up to continue maintaining it (if there is a need
to maintain it).

Florian


What about SCGI and AJP support? Is that going?

Seems silly to drop FastCGI which is probably the most popular of three 
and leave the other two intact. If you're going to drop something drop 
all three.


At least then it is clear to users that WSGI is the only supported 
option in Django.


Third parties can then maintain FastCGI, SCGI and AJP support (which I 
believe all come from flup anayway).


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

[Florian Apolloner]

On Monday, July 15, 2013 4:14:43 PM UTC+2, Jannis Leidel wrote:
>
> If you're suggesting to move the FastCGI code into a separate app: +1 
>

I'd have just dropped it, but yes we can move it out; although someone else 
will have to step up to continue maintaining it (if there is a need to 
maintain it).

Florian

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

[Jannis Leidel]

On 14.07.2013, at 21:17, Florian Apolloner  wrote:

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

If you're suggesting to move the FastCGI code into a separate app: +1

In other words, I don't think we can remove it from Django and not provide a 
migration path for FastCGI users. It's simple enough to move the runfcgi 
management command and the flup based handler into a separate app without 
having to risk changes in behavior.

Jannis

PS: I've just registered django-fcgi on PyPI in case you want to release it 
under that name.

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

[Some Developer]

On 15/07/13 13:13, mjl Martin J. Laubach wrote:

   Is there actually a problem with flup? Not being maintained doesn't
mean it's totally broken and it obviously works just fine for a lot of
folks?

 mjl


I use it myself and haven't had any issues with it either I was just 
responding to one of the previous posters who stated that because flup 
was unmaintained it was a good reason to deprecate FastCGI in Django. He 
did make a good point about there being no bug tracker but as I said if 
it became a critical issue then a fork is always on the cards.


I'd be interested if any contact has been made with the author of flup 
to see whether he has dropped the project or whether he just doesn't get 
any bug reports warranting a new release.


Personally I haven't had any issues with flup at all. In fact for me 
Django with flup + nginx + daemontools works wonderfully for production 
sites. Perhaps not as fast as uWSGI but it is solid enough.


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

[Florian Apolloner]

On Monday, July 15, 2013 7:07:08 AM UTC+2, Russell Keith-Magee wrote:
>
> 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.
>

We won't cut anything off (maybe aside from the runfcgi command). 
Supporting FCGI should be as easy as shown in the flask docs: 
http://flask.pocoo.org/docs/deploying/fastcgi/ -- This means that even if 
we remove everything FCGI specific from Django this doesn't prevent people 
from using FCGI+Django, it just means they have a bit more work to do 
(although if you look at the flask docs, it's really just a .fcgi file).

Cheers,
Florian

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

[Russell Keith-Magee]

If it were just Hostgator that was the problem, that might be a worthwhile
approach. But that's not the true scope of the problem. We're talking about
every hosting provider in the "$5 per month" hosting category that
currently supports PHP, and provides FCGI as the fastest way they can
support any other framework without having to think too hard.

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.

Yours,
Russ Magee %-)

On Mon, Jul 15, 2013 at 1:04 PM, Michael Manfre  wrote:

> Has anyone thought to contact HostGator and see how they would react to
> Django dropping FastCGI and/or whether they would be willing to support a
> WSGI option.
>
> Regards,
> Michael Manfre
>
>
> On Mon, Jul 15, 2013 at 12:44 AM, Russell Keith-Magee <
> russ...@keith-magee.com> wrote:
>
>>
>> On Mon, Jul 15, 2013 at 10:06 AM, Curtis Maloney <
>> cur...@acommoncreative.com> wrote:
>>
>>> 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... :)]
>>>
>>
>> This would be my concern as well.
>>
>> I have no love for FastCGI as a platform, but there's a wide range of
>> hosting providers out there, especially at the cheap end, that don't
>> provide a WSGI option.
>>
>> The right option here may well be to say "Tough Luck" to these people and
>> and encourage them to move to different hosting providers. However, I don't
>> want to rush into this decision without considering the effect on the low
>> end of our user base.
>>
>> Yours,
>> Russ Magee %-)
>>
>>  --
>> 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.
>
>
>

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

[Michael Manfre]

Has anyone thought to contact HostGator and see how they would react to
Django dropping FastCGI and/or whether they would be willing to support a
WSGI option.

Regards,
Michael Manfre


On Mon, Jul 15, 2013 at 12:44 AM, Russell Keith-Magee <
russ...@keith-magee.com> wrote:

>
> On Mon, Jul 15, 2013 at 10:06 AM, Curtis Maloney <
> cur...@acommoncreative.com> wrote:
>
>> 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... :)]
>>
>
> This would be my concern as well.
>
> I have no love for FastCGI as a platform, but there's a wide range of
> hosting providers out there, especially at the cheap end, that don't
> provide a WSGI option.
>
> The right option here may well be to say "Tough Luck" to these people and
> and encourage them to move to different hosting providers. However, I don't
> want to rush into this decision without considering the effect on the low
> end of our user base.
>
> Yours,
> Russ Magee %-)
>
>  --
> 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

[Russell Keith-Magee]

On Mon, Jul 15, 2013 at 10:06 AM, Curtis Maloney  wrote:

> 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... :)]
>

This would be my concern as well.

I have no love for FastCGI as a platform, but there's a wide range of
hosting providers out there, especially at the cheap end, that don't
provide a WSGI option.

The right option here may well be to say "Tough Luck" to these people and
and encourage them to move to different hosting providers. However, I don't
want to rush into this decision without considering the effect on the low
end of our user base.

Yours,
Russ Magee %-)

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

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... :)]

--
Curtis Maloney



On 15 July 2013 11:35, gilberto dos santos alves  wrote:

> i start 2 months ago using fcgi inside an shared host (hostgator.com)
> and after lots of tries with wsgi only using fcgi was worked with
> apache2. but i will read and learn about uwsgi and try this. my app
> use version 1.6a of django is 1.6b worked using python 2.6. because
> parts of my app is with status development i will test this with
> python 2.7 too. but i agree that docs is not clear, because they mixed
> concepts of apache2 and django (directories static, admin etc). i am
> reviewing these docs soon for clarify concepts about wsgi, fcgi and if
> necessary uwsgi. If someone have advices or additional ref. is
> welcome! ;>)
>
> 2013/7/14 Florian Apolloner :
> > 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
> >
> > --
> > 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.
> >
> >
>
>
>
> --
> gilberto dos santos alves
> +55.11.98646-5049
> sao paulo - sp - brasil
>
> --
> 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

[gilberto dos santos alves]

i start 2 months ago using fcgi inside an shared host (hostgator.com)
and after lots of tries with wsgi only using fcgi was worked with
apache2. but i will read and learn about uwsgi and try this. my app
use version 1.6a of django is 1.6b worked using python 2.6. because
parts of my app is with status development i will test this with
python 2.7 too. but i agree that docs is not clear, because they mixed
concepts of apache2 and django (directories static, admin etc). i am
reviewing these docs soon for clarify concepts about wsgi, fcgi and if
necessary uwsgi. If someone have advices or additional ref. is
welcome! ;>)

2013/7/14 Florian Apolloner :
> 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
>
> --
> 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.
>
>



-- 
gilberto dos santos alves
+55.11.98646-5049
sao paulo - sp - brasil

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