Re: [Web-SIG] Starting Web Servers using socket FDs
Just a follow-up on this: an --socket fd://xx option was added to uWsgi, and meinheld can now be started with a socket_fd option, I will try to propose the same option in other web servers. Thanks to Roberto Yutaka for these changes Cheers Tarek ___ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
[Web-SIG] Starting Web Servers using socket FDs
Hey I am doing this experimentation where the WGSI server is not started with an host/port or a unix socket, but rather a FD value, corresponding to a socket already bound by the parent process. The server would then just accept new connection on the FD, using socket.fromfd() to get a socket object back, and forget about all the binding work. Here's a prototype based on wsgiref : https://github.com/tarekziade/chaussette The goal I have is to be able to just spawn web workers using subprocess and take care myself of the process management part. I wrote a blog post on my motivations here : http://blog.ziade.org/2012/06/12/shared-sockets-in-circus if you want more background. Anyways, the idea I wanted to bring here was the following: most web servers out there support regular host/port or Unix Socket, which are usually the unix: prefix followed by a path on the system. What if web servers had these two standards *and* a new one which would be a fd: prefix. For instance, we would start server foo with: $ foo --fd:12:localhost:8080 Where 12 is the fd number the foo server would use for getting the socket, and localhost:8080 would just be there as an information to be able to fill some WGSI headers that requires it. From there I could just spawn foo and pass to it socket.fileno() Thoughts ? Cheers Tarek ___ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
Re: [Web-SIG] Starting Web Servers using socket FDs
On 6/5/12 11:46 AM, Roberto De Ioris wrote: ... Gunicorn can already bind (or better, accept) from file descriptors specifying an environment variable. I don't think you can start gunicorn using a file descriptor, or I failed to do it. The best I was able to do was to create a small wsgi server using Gunicorn as a lib. Gunicorn uses an environment variable when it respawns workers but it does not offer it as a public option as far as I understand how it works uWSGI supports by-default the inheritance of file descriptor 0 for fcgi-like startup, and working on generic file descriptor or inet/upstart/systemd socket activation. I did not find a way to start it using a provided fd -- they are plethora of options though, maybe I missed it The vast majority of modern systems expects the file descriptor number on an environment variable: upstart: UPSTART_FDS systemd: LISTEN_FDS Yes, this seem fairly standard. Circus, could follow the same behaviour, but i do not know if a standard will be required for that. The goal of the standard is just to be able to place any wsgi server out there and have it working out of the box. So far I was not able to run an existing wsgi server like this without changing its code because they all make the assumption they will be run with a host and port. Regarding the --fd:12:localhost:8080 syntax, is redundant as you can get the name of the socket mapped to a file descriptor with getsockname: http://linux.die.net/man/2/getsockname Will look into this again, I had an issue trying to do it. Thanks for the feedback! -- Roberto De Ioris http://unbit.it JID: robe...@jabber.unbit.it ___ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
Re: [Web-SIG] Starting Web Servers using socket FDs
On 6/5/12 11:41 AM, anatoly techtonik wrote: On Tue, Jun 5, 2012 at 12:30 PM, Tarek Ziadéta...@ziade.org wrote: Thoughts ? I've skimmed over the text and couldn't find any user story. What is the end goal? use a web server as a standalone, isolated process, with nothing but a single main thread that gets request then send back response. then have Circus do all the processes management. What is the responsibility of web server, web app and your controlling app? - The web server accept() connections on a socket and transforms a request into a wsgi environ it passes to a wsgi application [Meinheld, Bjoern, Whatever..] - The web app is a classical wsgi application that handles start_response and return a list of strings [the application that follows the wsgi standard] - The controlling app manages the life of the sockets and also manage the life of web app processes [Circus] Who should control keep-alives and connection drops? I don't know I did not get into those details yet. Cheers Tarek ___ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
Re: [Web-SIG] Starting Web Servers using socket FDs
On 6/5/12 12:31 PM, Benoit Chesneau wrote: On Tue, Jun 5, 2012 at 12:26 PM, Tarek Ziadéta...@ziade.org wrote: On 6/5/12 11:46 AM, Roberto De Ioris wrote: ... Gunicorn can already bind (or better, accept) from file descriptors specifying an environment variable. I don't think you can start gunicorn using a file descriptor, or I failed to do it. The best I was able to do was to create a small wsgi server using Gunicorn as a lib. Gunicorn uses an environment variable when it respawns workers but it does not offer it as a public option as far as I understand how it works export GUNICORN_FD=your fd and then gunicorn will use this file descriptor when it starts. But it should be possible to pass it directly using a config option if it's needed. What you be great then is to be able to run Gunicorn as a single process without having it forking workers, because the main goal is to be able to manage that process directly in Circus -- e.g. skip all the arbiter part in Gunicorn My attempt at this was this hack : https://github.com/tarekziade/chaussette/commit/075003a24ffe92253da60aafc6f99062e0af267d#diff-3 Cheers Tarek - benoît ___ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
Re: [Web-SIG] Starting Web Servers using socket FDs
On 6/5/12 1:56 PM, Roberto De Ioris wrote: uWSGI supports by-default the inheritance of file descriptor 0 for fcgi-like startup, and working on generic file descriptor or inet/upstart/systemd socket activation. I did not find a way to start it using a provided fd -- they are plethora of options though, maybe I missed it it is automatic if the fd is the zero one, otherwise you have to authenticate it adding a --socket/--http-socket/--fastcgi-socket directive mapping to the address (this is required for avoiding uWSGI inheriting unrelated sockets, like the ones created by ssh-agents and whatever you want). For example if you map fd 17 to 192.168.1.1:4040 you have to run uwsgi with --socket 192.168.1.1:4040 it will find fd 17 mapped to a socket, and it will know the socket is authorized to be used. Other components take the special fd://n syntax (like the various routers) but i do not think you are intersted in them Great, thanks, will try this The vast majority of modern systems expects the file descriptor number on an environment variable: upstart: UPSTART_FDS systemd: LISTEN_FDS Yes, this seem fairly standard. Circus, could follow the same behaviour, but i do not know if a standard will be required for that. The goal of the standard is just to be able to place any wsgi server out there and have it working out of the box. if this is your objective i suggest you to follow the inetd/fastcgi style approach and use file descriptor 0 as the communication socket. Flup and uWSGI will work over this automatically. Gunicorn will work simply adding GUNICORN_FD=0 Adding another env-var will mean each server will need to add a condition for that (like upstart and systemd) The thing is, the main process might bind several sockets, and have various subprocesses linked to specific ones, so I guess the uWsgi --socket approach is the most straightforward Thanks for all the info -- Roberto De Ioris http://unbit.it JID: robe...@jabber.unbit.it ___ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
Re: [Web-SIG] A 'shutdown' function in WSGI
On Tue, Feb 21, 2012 at 8:56 AM, Simon Sapin simon.sa...@exyr.org wrote: Le 21/02/2012 08:47, Tarek Ziadé a écrit : Yes, I also think shutting down the server is completely orthogonal to requests. If the shutdown callback is next to the application and not registered in a request, why not also have the symmetric server start up callback that would not wait for a request? This would avoid workarounds like Flask.before_first_request. Both of these callbacks could be called once per process (aka. space where requests share memory.) Fair point, Instead of having to provide two or three objects separately to a server, how about making the callbacks attributes of the application callable? can you show us an example ? Regards, -- Simon Sapin -- Tarek Ziadé | http://ziade.org ___ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
Re: [Web-SIG] A 'shutdown' function in WSGI
On Tue, Feb 21, 2012 at 10:24 AM, Graham Dumpleton graham.dumple...@gmail.com wrote: ... But I don't think you can guarantee that everything is still up in memory by the time atexit gets called, so you can't really call cleanup code there. The only thing which is done prior to atexit callbacks being called is waiting on threads which weren't marked as daemonised. which can lead to completely lock the shutdown if a lib or the program has a thread with a loop that waits for a condition. which it is not the case with signals, since you get a chance to properly stop everything beforehand. what do you mean by bypassing its destruction ? Non catchable signal from within process or from a distinct monitoring process. One of this things I pointed out is being missed. That is, a WSGI adapter may be running on top of another layer of abstraction, such as FASTCGI for example, where the lower layer isn't going to have any callback mechanism of its own to even notify the WSGI layer to trigger registered cleanup callbacks. This is why the only mechanism one can universally rely on is the Python interpreters own atexit mechanism. I see.. but what I don't understand is the following: when the whole stack is shut down, the python process is being killed by *someone*. And that someone, as far as I understand, is also able to send requests to the WSGI application. So what makes it impossible to send a shutdown signal prior to killing the process ? Sorry if I miss the obvious, I am probably over-simplifying things here :d Cheers Tarek -- Tarek Ziadé | http://ziade.org ___ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
Re: [Web-SIG] A 'shutdown' function in WSGI
On Tue, Feb 21, 2012 at 11:07 AM, Simon Sapin simon.sa...@exyr.org wrote: ... So a super-set of WSGI that is not just a gateway but also does process management? @contextlib.contextmanager def super_application(server_**infos): with contextlib.closing(open_**resource()) as resource: wsgi_callable = make_app(server_infos, resource) yield wsgi_callable I like this form a lot, but I think this is an implementation detail -- since we've not answered to the main question yet. Here's my attempt to formulate how I understand the problem at this point current assumptions/limitations: - the application can be shutdown without handling a request / which makes it orthogonal to the requests handling - the underlying code may use threads, making it unreliable to use atexit() - using signals may be problematic if some other code use it too -- for example the wsgi server itself - the cleanest way seems to ask the web server itself to ping the wsgi app. problems: - how can we declare a shutdown entry point in the application, the web server can use. - how can this work with extra indirections (FASTCGI, etc) leads: - define startup/shutdown functions, declare them to the web server - use the existing environ to send a 'shutdown request' - Cheers Tarek -- Tarek Ziadé | http://ziade.org ___ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
Re: [Web-SIG] A 'shutdown' function in WSGI
On Tue, Feb 21, 2012 at 1:43 PM, Antoine Pitrou solip...@pitrou.net wrote: Tarek Ziadé ziade.tarek@... writes: On Tue, Feb 21, 2012 at 10:24 AM, Graham Dumpleton graham.dumple...@gmail.com wrote: ... But I don't think you can guarantee that everything is still up in memory by the time atexit gets called, so you can't really call cleanup code there. The only thing which is done prior to atexit callbacks being called is waiting on threads which weren't marked as daemonised. which can lead to completely lock the shutdown if a lib or the program has a thread with a loop that waits for a condition.which it is not the case with signals, since you get a chance to properly stop everything beforehand. That's a buggy lib or program. This has nothing to do with WSGI really. No, that has to do with : please let me clean my program before you try to kill it because I can't use signals :) The snippet Graham showed is run at any interpreter shutdown, even when you simply run python in your shell. here's a very simple demo: http://tarek.pastebin.mozilla.org/1489505 Run it with plain python, and try to ctrl-C it. You won't reach atexit and will get locked. (here: python 2.7 / mac os) If you use signals instead of atexit, you'll have it working. And this pattern (a thread in the background) is pretty common -- unless I am missing something here Cheers Tarek Regards Antoine. ___ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/ziade.tarek%40gmail.com -- Tarek Ziadé | http://ziade.org ___ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
Re: [Web-SIG] A 'shutdown' function in WSGI
On Tue, Feb 21, 2012 at 2:46 PM, Tarek Ziadé ziade.ta...@gmail.com wrote: here's a very simple demo: http://tarek.pastebin.mozilla.org/1489505 There are two typos but the effect remains the same since you are locked before you reach those lines: - atexit call worker.stop() instead of worker.join() - in worker.stop(), it calls worker.join() instead of worker.join(self) -- Tarek Ziadé | http://ziade.org ___ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
Re: [Web-SIG] A 'shutdown' function in WSGI
On Tue, Feb 21, 2012 at 3:02 PM, Antoine Pitrou solip...@pitrou.net wrote: ... I find your example convincing. I think that's worth fixing in Python (e.g. by offering an atexit() method on Thread objects). Perhaps you can open a bug? Sure yeah -- Notice that I think it's still a good idea to provide the shutdown function in WSGI, because it gives the full control to the web server on the ordering of events. Cheers Tarek Regards Antoine. ___ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/ziade.tarek%40gmail.com -- Tarek Ziadé | http://ziade.org ___ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
[Web-SIG] A 'shutdown' function in WSGI
Hello I need to be able to call a function when the web application shuts down (SIGTERM/SIGINT) -- the use case is to stop a background thread. I am currently using signals because it seems to be the most clean way to do this. atexit is much trickier since you don't know when it's going to get called and you might try to call objects that were garbage collected unless you hack something to keep references alive. But signals are also tricky beasts since you may compete with other code that are listening to them. For instance mod_wsgi don't like apps that have signal handlers. Anyways, the bottom line is that the cleanest way to do this -- as per Chris McDonough idea, would be to introduce in the WSGI protocol a shutdown function the servers would be obligated to call before exiting. I am not sure yet about its arguments, maybe a signum + frame or simply an exit code... But how do you like the idea ? That would solve for me the problem of having to deal differently here depending on if I am called with mod_wsgi or gunicorn or xxx Cheers Tarek -- Tarek Ziadé | http://ziade.org ___ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
Re: [Web-SIG] A 'shutdown' function in WSGI
On Mon, Feb 20, 2012 at 8:09 PM, Eric Larson e...@ionrock.org wrote:
CherryPy provides a bus that allows you to add events to the web server
process. It is specified pretty clearly and CherryPy recently made it
available as a standalone package, Magicbus (
https://bitbucket.org/cherrypy/magicbus/overview). Specifically it allows
you to send events on different signals the main server process might get.
You can also use it for a general bus within the app server, but at its
most basic level, the goal was to make the stop/start/restart events easy
to hook into.
I've found it to be really helpful for managing processes and wrote a
simple supervisor-ish app called Dad using it (
http://bitbucket.org/elarson/dad).
Thanks for the pointer -- that looks pretty neat
I would be more interested though, in defining an extension to the WSGI
standard
A rough example of what I am talking about:
If I take the wsgiref doc, here's an example of a minimal wsgi application
(myapp.py):
from wsgiref.simple_server import make_server
def hello_world_app(environ, start_response):
status = '200 OK' # HTTP Status
headers = [('Content-type', 'text/plain')]
start_response(status, headers)
return [Hello World]
def main():
return make_server('', 8000, hello_world_app)
That module can be run by any web server out there that understands WSGI.
For instance, with gunicorn I can do:
$ gunicorn myapp:main
What I am talking about is a second entry point for the shutdown - example:
from wsgiref.simple_server import make_server
def hello_world_app(environ, start_response):
status = '200 OK' # HTTP Status
headers = [('Content-type', 'text/plain')]
start_response(status, headers)
return [Hello World]
def main():
return make_server('', 8000, hello_world_app)
def shutdown(): # or maybe something else as an argument I don't know
do_some_cleanup()
And point the shutdown callable to a web server:
$ gunicorn myapp:main myapp:shutdown
If this is defined in the WSGI standard it means any wsgi web server could
call shutdown() , not only gunicorn
Cheers
Tarek
HTH
Eric
--
Eric Larson
On Monday, February 20, 2012 at 10:03 AM, Tarek Ziadé wrote:
Hello
I need to be able to call a function when the web application shuts down
(SIGTERM/SIGINT) -- the use case is to stop a background thread.
I am currently using signals because it seems to be the most clean way
to do this. atexit is much trickier since you don't know when it's going to
get called and you might try to call objects that were garbage collected
unless you hack something to keep references alive.
But signals are also tricky beasts since you may compete with other code
that are listening to them. For instance mod_wsgi don't like apps that have
signal handlers.
Anyways, the bottom line is that the cleanest way to do this -- as per
Chris McDonough idea, would be to introduce in the WSGI protocol a
shutdown function the servers would be obligated to call before exiting.
I am not sure yet about its arguments, maybe a signum + frame or simply
an exit code...
But how do you like the idea ? That would solve for me the problem of
having to deal differently here depending on if I am called with mod_wsgi
or gunicorn or xxx
Cheers
Tarek
--
Tarek Ziadé | http://ziade.org
___
Web-SIG mailing list
Web-SIG@python.org (mailto:Web-SIG@python.org)
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe:
http://mail.python.org/mailman/options/web-sig/eric%40ionrock.org
--
Tarek Ziadé | http://ziade.org
___
Web-SIG mailing list
Web-SIG@python.org
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe:
http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
Re: [Web-SIG] A 'shutdown' function in WSGI
oops my examples were broken, should be:
def hello_world_app(environ, start_response):
status = '200 OK' # HTTP Status
headers = [('Content-type', 'text/plain')]
start_response(status, headers)
return [Hello World]
def shutdown(): # or maybe something else as an argument I don't know
do_some_cleanup()
and:
$ gunicorn myapp:hello_world_app myapp:shutdown
Cheers
Tarek
___
Web-SIG mailing list
Web-SIG@python.org
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe:
http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
Re: [Web-SIG] A 'shutdown' function in WSGI
2012/2/21 Chris McDonough chr...@plope.com On Mon, 2012-02-20 at 20:54 -0500, PJ Eby wrote: 2012/2/20 Chris McDonough chr...@plope.com On Mon, 2012-02-20 at 17:39 -0500, PJ Eby wrote: The standard way to do this would be to define an optional server extension API supplied in the environ; for example, a 'x-wsgiorg.register_shutdown' function. Unlikely, AFACIT, as shutdown may happen when no request is active. Even if this somehow happened to not be the case, asking the application to put it in the environ is not useful, as the environ can't really be relied on to retain values up the call stack. Optional server extension APIs are things that the server puts in the environ, not things the app puts there. That's why it's 'register_shutdown', e.g. environ['x-wsgiorg.register_shutdown'](shutdown_function). I get it now, but it's still not the right thing I don't think. Servers shut down without issuing any requests at all. Yes, I also think shutting down the server is completely orthogonal to requests. Maybe another option would be to call the application with the usual callable, but an ending request that's a signal for the application about being shut down. When the app receives that very specific request, it would do the cleaning job. It sounds hackish but would work without changing the standard - C -- Tarek Ziadé | http://ziade.org ___ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
Re: [Web-SIG] A 'shutdown' function in WSGI
On Tue, Feb 21, 2012 at 2:39 AM, Graham Dumpleton graham.dumple...@gmail.com wrote: ... Overall the best chance of being able to do anything is relying on atexit. You are though at the mercy of the WSGI hosting mechanism shutting down the process and so the interpreter, in an orderly manner such that atexit callbacks get called. In Apache/mod_wsgi you get this guarantee, even in sub interpreters where atexit callbacks wouldn't normally be called when they are destroyed. For uWSGI, atexit callbacks will not be called at the moment, by Robert is making changes to it so you get a guarantee there as well. It is possible he is only doing this though for case where main interpreter is being used, as doing it for sub interpreters is a bit fiddly. But I don't think you can guarantee that everything is still up in memory by the time atexit gets called, so you can't really call cleanup code there. Any pure Python WSGI servers shouldn't have issues so long as they aren't force exiting the whole process and bypassing normal interpreter destruction. what do you mean by bypassing its destruction ? Cheers Tarek Graham ___ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/ziade.tarek%40gmail.com -- Tarek Ziadé | http://ziade.org ___ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
Re: [Web-SIG] PEP 444 (aka Web3)
On Thu, Sep 16, 2010 at 1:57 PM, Armin Ronacher armin.ronac...@active-4.com wrote: Hi, On 9/16/10 1:44 PM, Tarek Ziadé wrote: I propose to write in the PEP that a middleware should provide an app attribute to get the wrapped application or middleware. It seems to be the most common name used out there. What about middlewares that encapsulate more than one application? True... I don't know what's the best option here.. I guess we need to provide all children so one may visit the whole graph. Do you have a list of middleware that does this ? Regards Tarek -- Tarek Ziadé | http://ziade.org ___ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
Re: [Web-SIG] PEP 444 (aka Web3)
On Thu, Sep 16, 2010 at 2:40 PM, Armin Ronacher armin.ronac...@active-4.com wrote: Hi, On 9/16/10 2:38 PM, Tarek Ziadé wrote: True... I don't know what's the best option here.. I guess we need to provide all children so one may visit the whole graph. Another gripe I have with WSGI is that if you attempt to combine applications together with a dispatcher middleware, the inner application does not know the URL of the outer one. It's SCRIPT_NAME points to itself and there is no ORIGINAL_SCRIPT_NAME. Do you have a list of middleware that does this ? I know that Paste has a cascade middleware and I think it also has one that maps applications to specific prefixes. Ah yes, the composite thing IIRC - I didn't know this was a middleware. Should those be middlewares ? ISTM that they should in the front of the stack instead, and that a stack of middleware should be dedicated to a single application -- for the griefs you mentioned and probably other problems. I mean, one call does not visit several application, and this is some kind of dynamic rewriting of the stack.. Another possibility would be to define a get_application(environ=None) method so the middleware is able to return the right app at the right moment Regards, Armin -- Tarek Ziadé | http://ziade.org ___ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
Re: [Web-SIG] PEP 444 (aka Web3)
On Thu, Sep 16, 2010 at 2:57 PM, Masklinn maskl...@masklinn.net wrote: On 2010-09-16, at 18:08 , Tarek Ziadé wrote: On Thu, Sep 16, 2010 at 1:57 PM, Armin Ronacher armin.ronac...@active-4.com wrote: Hi, On 9/16/10 1:44 PM, Tarek Ziadé wrote: I propose to write in the PEP that a middleware should provide an app attribute to get the wrapped application or middleware. It seems to be the most common name used out there. What about middlewares that encapsulate more than one application? True... I don't know what's the best option here.. I guess we need to provide all children so one may visit the whole graph. That would require a hypothetical self.app to always be a list, or at least an iterable, right? I would prefer a get_application(environ=None) iterator that would reach the final application depending on the environment, and return only one app or middleware per level, but I am not sure... -- Tarek Ziadé | http://ziade.org ___ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
