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
> -- t
On Mon, Jul 15, 2013 at 3:02 PM, Juan Luis Boya wrote:
> I've posted a patch for runfcgi here:
>
> https://code.djangoproject.com/ticket/20751
>
> It includes documentation update and unit tests, for anyone interested, if
> any.
Juan Luis,
This is all great work. Thank you very much for it.
The
Hello,
I apologize for the lack of updates on the progress of my project in
the past few weeks, there just wasn't much to report, unfortunately.
I spent the past two weeks porting the ForeignKey refactor on top of
master. It took significantly more time to do than I anticipated due
to all the cha
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 bas
On Mon, Jul 15, 2013 at 1:34 PM, Daniel Ellis wrote:
> Is it considered gauche to revive old topics such as this?
It's not, but my opinion hasn't changed -- I'm still -1, and so's Adrian.
So unless you've got something really convincing, an argument that hasn't
been presented yet that is totall
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
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
Is it considered gauche to revive old topics such as this? After having
some difficulty debugging why an if statement was throwing a strange error,
I realized it was because they didn't support multi-line statements.
Here's what I was trying:
{% if request.xxx.family.get_selected.get_age < pr
On 15 juil. 2013, at 03:20, Ramiro Morales wrote:
> Would it be worth look at the web server log to see if these comments
> were effectively created by HTTP POST requests at all?
As far as I can tell, the spammer is using regular requests. While he has a
browser-like user-agent, he's using HTTP
On 15 juil. 2013, at 14:13, mjl Martin J. Laubach wrote:
> Is there actually a problem with flup?
Yes, there are.
About a hundred tickets related to fastcgi or flup were reported in the history
of Django: https://code.djangoproject.com/search?q=flup&ticket=on
https://code.djangoproject.com/s
/Disclaimer: I don't know much about FCGI. I've never used it and I don't plan
to. Please forgive me if I say something stupid./
For 4,5 years (August 2008 to March 2013), we've had a silly bug in Django that
was a workaround for a bug in flup, and to this day no one can say if the
original bug
I've posted a patch for runfcgi here:
https://code.djangoproject.com/ticket/20751
It includes documentation update and unit tests, for anyone interested, if
any.
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To unsubscribe from this gr
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 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…
--
You receiv
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 i
Hi Jannis and Ramiro,
On 07/14/2013 07:16 AM, Jannis Leidel wrote:
> Yeah, I can relate to that, it does to me, too. I think decoupling
> the file serving slightly from how the files got to the place they
> are served from, is a good first step. The common denominator between
> the core ability to
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 mai
Hi Jannis, Thanks for your reply,
On Sun, Jul 14, 2013 at 10:16 AM, Jannis Leidel wrote:
>
> I'm pretty sure we don't want to increase the code that deals with
> serving files. We've repeatedly improved the documentation about
> helping users to configure their web server to serve the files inste
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
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
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
Progress: I've implemented manager checks.
The schedule for the next 4 weeks is:
1. Manager checks (ref 4.1.7)(done)(0.5 week).
2. Entry point registering (ref 4.1.5) & rewriting mechanism of triggering
checking framework (ref 4.1.9)(1.5 week).
3. Moving custom User model checks (ref 4.1.6)(0.
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
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To unsubscribe from this group
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
htt
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
On Monday, July 15, 2013 3:20:16 AM UTC+2, Ramiro Morales wrote:
>
> Would it be worth look at the web server log to see if these comments
> were effectively created by HTTP POST requests at all?
>
That's what I did to figure out the ip (which I blocked via iptables before
Aymeric played with
26 matches
Mail list logo
