On Apr 7, 6:47 am, Travis Parker <travis.par...@gmail.com> wrote:
> A first stab at the translators is up on github 
> athttp://github.com/teepark/django/tree/50b1e97cec14221a846a6338c40f585...
>
> I've done django views -> wsgi apps, wsgi apps -> django views, and
> django middleware -> wsgi middleware. i still think that going from
> wsgi middleware to django middleware would be impossible, but i intend
> to write a translator of wsgi middleware to django view decorators. it
> also needs more tests.
>
> A couple of sticky points I have hit so far:
> 1. some of the information required in a WSGI environ dictionary isn't
> necessarily available to django (SERVER_PROTOCOL (HTTP version 1.0 or
> 1.1), wsgi.multithread, wsgi.multiprocess)

For WSGI hosting mechanisms, you should be able to get these from the
original WSGI environment dictionary. I thought that was accessible in
some way.

For mod_python can't you get to the original mod_python request object
and grab req.protocol for SERVER_PROTOCOL. For the multithread/
multiprocess, if using mod_python 3.X, you can use the
mod_python.apache.mpm_query function.

So, you need to know whether you are using WSGI or mod_python, but
should be ways of doing it.

>   - I used SERVER_PROTOCOL 1.1, multithread True, multiprocess True as
> I think those are the more demanding answers, so safer since we don't
> know

By setting multiprocess to be True, you prevent though people using
things like EvalException, the in browser debugging tool which is
included in Paste. That specifically checks whether multiprocess or
not, as can't work in multiprocess configuration as requests must be
guaranteed to come back to same process.

Graham

> 2. process_view in django middleware - when turning it into a wsgi
> middleware, there is no view, so what to do with it?
>   - my answer right now is go ahead and call it, passing it the
> wrapped wsgi app.
>
> i'd love comments or suggestions.
>
> travis
>
> On Mar 31, 1:29 pm, Travis Parker <travis.par...@gmail.com> wrote:
>
> > On Tue, Mar 31, 2009 at 1:12 PM, Waylan Limberg <way...@gmail.com> wrote:
>
> > > On Tue, Mar 31, 2009 at 2:21 PM, Travis Parker <travis.par...@gmail.com>
> > > wrote:
>
> > > [snip]
>
> > > > 2. settings (views -> apps, dj middleware -> wsgi middleware)
> > > > i don't have nearly as nice a proposal for dealing with this. there
> > > > are a lot of django views and middleware out there that would be nice
> > > > to have usable as wsgi components but which require
> > > > django.conf.settings to work. if they are going to go into a wsgi
> > > > environment though, it seems a little strange to require a
> > > > DJANGO_SETTINGS_MODULE environment variable and a django-style
> > > > settings.py. i don't have any great ideas. open for suggestions.
>
> > > [snip]
>
> > > It seems to be a little known/remembered fact that
> > > DJANGO_SETTINGS_MODULE and settings.py are not required to use django
> > > code that requires settings. Settings can actually be configured
> > > manually within python code calling settings.configure(). This way,
> > > you only actually set settings that you need. In fact, outside of the
> > > strict situation of a django project, it is the only way I deal with
> > > settings when using parts of django.
>
> > > See here for details:http://www.djangobook.com/en/1.0/appendixE/#cn57
>
> > > However, the trick is that you can only call settings.configure() once
> > > and it's possible that multiple middleware will need settings. On top
> > > of that, the user may use some of those middlewhere and not others
> > > and/or change the order of the middlewhere. You'll need some way to
> > > work out whether configure has been called for each middlewhere and
> > > only call it the first time. Not fun, but it's got to be better than
> > > dealing with DJANGO_SETTINGS_MODULE and settings.py.
>
> > > --
> > > ----
> > > \X/ /-\ `/ |_ /-\ |\|
> > > Waylan Limberg
>
> > perfect! thanks. the boolean settings.configured seems to indicate whether
> > it has been configured, so every middleware/app can just check that and
> > configure() if it hasn't been done yet.
>
> > checking off #2, which I expected to be the hard one.
>
> > travis
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to