Hello, everybody.
Sorry for re-opening this old conversation, but I still haven't heard from
you.
I'm not sure whether that means that there's no interest in this, or it's
just that you've been busy.
Cheers,
- Gustavo.
On Friday, September 6, 2013 11:51:01 AM U
rsday, April 18, 2013 9:22:34 AM UTC+1, Gustavo Narea wrote:
>
> Hello,
>
> Any update on this?
>
> Cheers.
>
> - Gustavo.
>
> On Friday, April 12, 2013 3:29:49 PM UTC+1, Gustavo Narea wrote:
>>
>> Hi Jacob,
>>
>> On Friday, April 12, 2013 3:09:40
Hello,
Any update on this?
Cheers.
- Gustavo.
On Friday, April 12, 2013 3:29:49 PM UTC+1, Gustavo Narea wrote:
>
> Hi Jacob,
>
> On Friday, April 12, 2013 3:09:40 PM UTC+1, Jacob Kaplan-Moss wrote:
>>
>> On Fri, Apr 12, 2013 at 8:54 AM, Gustavo Narea
>> wrot
Hi Jacob,
On Friday, April 12, 2013 3:09:40 PM UTC+1, Jacob Kaplan-Moss wrote:
>
> On Fri, Apr 12, 2013 at 8:54 AM, Gustavo Narea
> > wrote:
> > So I guess that means that it won't be considered for inclusion in
> Django?
> > If so, I'll close that ti
,
- Gustavo.
On Thursday, April 11, 2013 3:31:51 PM UTC+1, Gustavo Narea wrote:
>
> Hello, everybody.
>
> In the interest of finding a resolution to Ticket
> #12091<https://code.djangoproject.com/ticket/12091>, a
> 3-year-old ticket, I wanted to bring this issue to yo
and
introducing thread locals in django.conf may be controversial. But I guess
it might be useful to other people.
So, do you agree that Django should have built-in support for running WSGI
applications from inside views?
Thanks in advance!
- Gustavo Narea.
--
You received this message because
h X-Sendfile/X-Accel-Redirect/Location.
> In short, it is all a mess and trying to provide support for it in one
> bit of code is possibly asking a bit much.
I agree with you. However, I think trying to offer some kind of common
abstraction may still be beneficial.
Cheers.
--
Gustavo N
Sendfile"
header is a path on the filesystem. In Nginx (header "X-Accel-Redirect")
and CGI (heder "Location"), the path is a URL path within the same host.
--
Gustavo Narea.
Software Developer.
2degrees, Ltd. <http://www.2degreesnetwork.com/>.
--
You received this m
endfile. You wouldn't hard code the path to the file either, and
yet that's how I've done it in my example.
--
Gustavo Narea.
Software Developer.
2degrees, Ltd. <http://www.2degreesnetwork.com/>.
--
You received this message because you are subscribed to the Google Groups
Hi all,
Just to let you know that there's an X-Sendfile implementation for
WSGI apps (inc. Django), which also works with Nginx:
https://launchpad.net/wsgi-xsendfile
You can use it in Django views via twod.wsgi. For example:
"""
from twod.wsgi import call_wsgi_app
from xsendfile import NginxSend
Hello,
On 23 June, 01:00, Russell Keith-Magee
wrote:
> On Wed, Jun 23, 2010 at 7:22 AM, Gustavo Narea wrote:
> > To sum up, I'm proposing two things:
> > 1.- Making the WSGI handler the only handler.
> > 2.- If we want to keep mod_python support, use a mod_python<
Whoops, I wan't aware of this topic when I posted this:
http://groups.google.com/group/django-developers/browse_thread/thread/2e20f4ae486800a1
Anyway, I'm +1 on this.
On Jun 22, 10:47 pm, Robert Coup wrote:
> Hey folks,
>
> While people are throwing around 1.3 ideas... I think we should start
>
y.html
To sum up, I'm proposing two things:
1.- Making the WSGI handler the only handler.
2.- If we want to keep mod_python support, use a mod_python<->WSGI wrapper.
What do you think?
PS: You may want to see the latest comments on Ticket #8927:
http://code.djangoproject.com/ticket/
Hello.
On Jun 14, 1:39 pm, Russell Keith-Magee
wrote:
> Ok - at this point, I'm broadly happy with your proposals (subject to
> the caveats I've given along the way). The next step is to show us
> actual code. This won't get applied to trunk as a single monolithic
> "fix WSGI" patch - it needs to
ese hosting system specific fiddles
> should never need to be done by a user.
>
Right, I see your point.
--
Gustavo Narea.
Software Developer.
2degrees, Ltd. <http://www.2degreesnetwork.com/>.
--
You received this message because you are subscribed to the Google Groups
"Django
a what those problems are, so I never meant to solve them.
I just found two issues and Paste Deploy/Script seemed like a solution.
I'm curious about them though. I'll keep an eye on your blog and Web-SIG.
--
Gustavo Narea.
Software Developer.
2degrees, Ltd. <http://www.2degree
Ob would be a bad idea?
Cheers.
--
Gustavo Narea .
| Tech blog: =Gustavo/(+blog)/tech ~ About me: =Gustavo/about |
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.
face during last year's GSoC. Are you at all
> >> familiar with the work on this branch? If so, what is the extent of
> >> the overlap between your code and that branch?
> >
> > AFAIR, that branch would've solved (3) only.
>
> It might only solve (3)
Hello,
Not that I want to rush this, but have you had time to read my last
email or made a decision? :-)
Cheers,
- Gustavo.
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develop...@googlegro
Hello, Russell et al.
I am not saying that Django's WSGI implementation doesn't comply with
the specification. In fact, I've been talking about improving "WSGI
support" not "WSGI compliance".
It does comply with the specification, but just internally without
exposing all the WSGI-related function
On Jun 2, 9:26 am, Reinout van Rees wrote:
> On 05/29/2010 01:51 AM, Gustavo Narea wrote:
> > Basically, when you need to integrate a piece of WSGI middleware that
> > must be present both on development and deployment, you have to get
> > rid of `manage runserver' an
ge the way
> Django works in order to support aspects of the WSGI spec that the
> Django community has been able to live without, or for which the
> Django community has alternate approaches. We're entirely happy to
> accept changes that make Django more WSGI compliant; we're
OMG, I didn't realize that the very long email I wrote last night was
trimmed by Google Groups.
Let me take a deep breath and write it again... :'(
On May 29, 12:51 am, Gustavo Narea wrote:
> Hello,
>
> On May 28, 6:13 pm, Russell Keith-Magee
> wrote:
>
>
Hello,
On May 28, 6:13 pm, Russell Keith-Magee
wrote:
> This is all very helpful information; thanks for breaking it down like this.
>
> I've talked this over with a few people at the sprints, and we've
> pretty much ended up at the same point -- we're deeply confused.
> Comments inline below.
T
Sorry, I forgot to link to the embedded application docs:
http://packages.python.org/twod.wsgi/manual/embedded-apps.html
On May 27, 10:08 am, Gustavo Narea
wrote:
> Hello,
>
> On May 26, 4:52 pm, Ivan Sagalaev wrote:
>
> > Could you please give a concise technical overview, i
Hello,
On May 26, 4:52 pm, Ivan Sagalaev wrote:
> Could you please give a concise technical overview, in high-level terms,
> on what twod.wsgi actually does to Django code?
Sure. There are different components, so I'll elaborate on them
individually:
Paste Deploy application factory instead of
Hello, Russell et al.
On May 24, 10:37 am, Russell Keith-Magee
wrote:
> We will be sprinting at the conference on Thursday and Friday. If you
> have a detailed proposal that would benefit from some round-table
> discussion while several core developers are in the same room, please
> post your pro
http://packages.python.org/twod.wsgi/manual/index.html#introduction
We're willing to work closely with the core development team to adapt twod.wsgi
if necessary and integrate it in Django 1.3.
What do you think?
- Gustavo Narea.
[1] http://packages.python.org/twod.wsgi/
[2]
http:
Hello,
I'm glad someone from the core development team brings this up.
I've lost motivation to contribute to Django after the many failed
attempts to improve WSGI support. I consider myself of the users Shawn
Milochik describes: "There is frustration on the part of some Django
users who would lik
I'd suggest using PasteDeploy:
http://packages.python.org/twod.wsgi/manual/paste-factory.html
I can't see a reason to reinvent the wheel with a Django-specific
thing, while this widely used method is rock-solid. It's the one used
in frameworks like Pylons and TurboGears,
On Feb 26, 7:11 am, Jared
Hello, Jari.
I'd recommend using twod.wsgi instead: http://bitbucket.org/2degrees/twod.wsgi/
It's very stable, full-feature and truly WSGI compliant. We've been
using heavily over the last 2 months. It started from this:
http://groups.google.com/group/django-developers/browse_thread/thread/08c7ff
; On Tue, Oct 27, 2009 at 10:49 PM, Gustavo Narea
> wrote:
> >
> > Hi there.
> >
> > Over the last week I've been working to improve WSGI support in Django
> > and I have sent a few patches which have not received the feedback I
> > expected to have, s
d really prefer to have this included in Django officially,
instead of having our patched version of Django.
If any of you is interested in trading tickets, please let me know. ;-)
Hoping-it-can-be-feasible'ly,
- Gustavo.
On Wed, 2009-10-28 at 09:58 +, Gustavo Narea wrote:
> Hello,
at you think,
- Gustavo.
On Wed, 2009-10-28 at 08:24 +0800, Russell Keith-Magee wrote:
> On Tue, Oct 27, 2009 at 10:49 PM, Gustavo Narea
> wrote:
> >
> > Hi there.
> >
> > Over the last week I've been working to improve WSGI support in Django
> > and
children" WSGI applications will be aware that the
user was authenticated.
Please let me know what you think about it!
Cheers. :)
[1] http://repoze.org/repoze_components.html#middleware
--
Gustavo Narea.
Software Developer.
2degrees, Ltd.
--~--~-~--~~~---~--~---
35 matches
Mail list logo
