PEP 444 (aka Web3)

classic Classic list List threaded Threaded
92 messages Options
12345
Reply | Threaded
Open this post in threaded view
|

PEP 444 (aka Web3)

Chris McDonough
A PEP was submitted and accepted today for a WSGI successor protocol
named Web3:

http://python.org/dev/peps/pep-0444/

I'd encourage other folks to suggest improvements to that spec or to
submit a competing spec, so we can get WSGI-on-Python3 settled soon.

- C


_______________________________________________
Web-SIG mailing list
[hidden email]
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe: http://mail.python.org/mailman/options/web-sig/lists%40nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: PEP 444 (aka Web3)

mdipierro
I fully support it!

Massimo

On Sep 15, 2010, at 6:03 PM, Chris McDonough wrote:

> A PEP was submitted and accepted today for a WSGI successor protocol
> named Web3:
>
> http://python.org/dev/peps/pep-0444/
>
> I'd encourage other folks to suggest improvements to that spec or to
> submit a competing spec, so we can get WSGI-on-Python3 settled soon.
>
> - C
>
>
> _______________________________________________
> Web-SIG mailing list
> [hidden email]
> Web SIG: http://www.python.org/sigs/web-sig
> Unsubscribe: http://mail.python.org/mailman/options/web-sig/mdipierro%40cti.depaul.edu

_______________________________________________
Web-SIG mailing list
[hidden email]
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe: http://mail.python.org/mailman/options/web-sig/lists%40nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: PEP 444 (aka Web3)

James Mills-3
On Thu, Sep 16, 2010 at 9:40 AM, Massimo Di Pierro
<[hidden email]> wrote:
> I fully support it!

I don't entirely. I don't quite agree with the key changes from wsgi
to web3. I think it's unnecessary.

cheers
james

--
-- James Mills
--
-- "Problems are solved by method"
_______________________________________________
Web-SIG mailing list
[hidden email]
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe: http://mail.python.org/mailman/options/web-sig/lists%40nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: PEP 444 (aka Web3)

PJ Eby
In reply to this post by Chris McDonough
At 07:03 PM 9/15/2010 -0400, Chris McDonough wrote:
>A PEP was submitted and accepted today for a WSGI successor protocol
>named Web3:
>
>http://python.org/dev/peps/pep-0444/
>
>I'd encourage other folks to suggest improvements to that spec or to
>submit a competing spec, so we can get WSGI-on-Python3 settled soon.

The first thing I notice is that web3.async appears to force all
existing middleware to delete it from the environment if it wishes to
remain compatible, unless it adapts to support receiving callables itself.

On further reading I see you have something about middleware
disabling itself if it doesn't support async execution, but this
doesn't make any sense to me: if it can't support async execution,
why wouldn't it just delete web3.async from the environ, forcing its
wrapped app to be synchronous instead?

I'm also not a fan of the bytes environ, or the new
path_info/script_name variables; note that the spec's sample CGI
implementation does not itself provide the new variables, and that
middleware must be explicitly written to handle the case where there
is duplication.

My main fear with this spec is that people will assume they can just
make a few superficial changes to run WSGI code on it, when in fact
it is deeply incompatible where middleware is concerned.  In fact,
AFAICT, it seems like it will be *harder* to write correct web3
middleware than it is to write correct WSGI middleware now.

This seems like a step backward, since the whole idea behind dropping
start_response() was to make correct middleware *easier* to write.

Any time a spec makes something optional or allows More Than One Way
To Do It, it immediately doubles the mimimum code required to
implement that portion of the spec in compliant middleware.  This
spec has two optionalities: web3.async, and the optional
path_info/script_name, so the return handling of every piece of
middleware is doubled (or else  "environ['web3.async'] = False" must
be added at the top), and any code that modifies paths must similarly
ditch the special variables or do double work to update them.
   

_______________________________________________
Web-SIG mailing list
[hidden email]
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe: http://mail.python.org/mailman/options/web-sig/lists%40nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: PEP 444 (aka Web3)

Chris McDonough
On Wed, 2010-09-15 at 20:05 -0400, P.J. Eby wrote:

> At 07:03 PM 9/15/2010 -0400, Chris McDonough wrote:
> >A PEP was submitted and accepted today for a WSGI successor protocol
> >named Web3:
> >
> >http://python.org/dev/peps/pep-0444/
> >
> >I'd encourage other folks to suggest improvements to that spec or to
> >submit a competing spec, so we can get WSGI-on-Python3 settled soon.
>
> The first thing I notice is that web3.async appears to force all
> existing middleware to delete it from the environment if it wishes to
> remain compatible, unless it adapts to support receiving callables itself.

We can ditch everything concerning web3.async as far as I'm concerned.
Ian has told me that this feature won't be liked by the async people
anyway, as it doesnt have a trigger mechanism.

> On further reading I see you have something about middleware
> disabling itself if it doesn't support async execution, but this
> doesn't make any sense to me: if it can't support async execution,
> why wouldn't it just delete web3.async from the environ, forcing its
> wrapped app to be synchronous instead?
>
> I'm also not a fan of the bytes environ, or the new
> path_info/script_name variables; note that the spec's sample CGI
> implementation does not itself provide the new variables, and that
> middleware must be explicitly written to handle the case where there
> is duplication.

I'm not concerned about which environment variables have it, but I would
definitely like to be able to get at the "original" (non-%2F-decoded)
path info somewhere.  I'd be fine if PATH_INFO was just that, and get
rid of web3.path_info.  web3.script_name is probably just a mistake
entirely.

> My main fear with this spec is that people will assume they can just
> make a few superficial changes to run WSGI code on it, when in fact
> it is deeply incompatible where middleware is concerned.  In fact,
> AFAICT, it seems like it will be *harder* to write correct web3
> middleware than it is to write correct WSGI middleware now.

I'm very willing to drop web3.async entirely.  It seems reasonable to do
so.  I should have done so before I mailed the spec, as I knew it would
be unpopular.

> This seems like a step backward, since the whole idea behind dropping
> start_response() was to make correct middleware *easier* to write.
>
> Any time a spec makes something optional or allows More Than One Way
> To Do It, it immediately doubles the mimimum code required to
> implement that portion of the spec in compliant middleware.  This
> spec has two optionalities: web3.async, and the optional
> path_info/script_name, so the return handling of every piece of
> middleware is doubled (or else  "environ['web3.async'] = False" must
> be added at the top), and any code that modifies paths must similarly
> ditch the special variables or do double work to update them.

No worries, let's get rid of both, with the caveat that it's pretty
essential (to me anyway) to be able to get at the non-%2F-encoded path
somewhere.  The most sensible thing to me would be to put it in
PATH_INFO.

As far as bytes vs. strings, whatever, we have to pick one.  Bytes makes
more sense to me.  I'll leave it to the native-string and/or unicode
people to create their own spec.

- C



_______________________________________________
Web-SIG mailing list
[hidden email]
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe: http://mail.python.org/mailman/options/web-sig/lists%40nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: PEP 444 (aka Web3)

James Mills-3
On Thu, Sep 16, 2010 at 10:15 AM, Chris McDonough <[hidden email]> wrote:
> We can ditch everything concerning web3.async as far as I'm concerned.
> Ian has told me that this feature won't be liked by the async people
> anyway, as it doesnt have a trigger mechanism.

You and Ian are right about that. I don't see the point of introducing
an "async" property/variable into the environment data.

cheers
James

--
-- James Mills
--
-- "Problems are solved by method"
_______________________________________________
Web-SIG mailing list
[hidden email]
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe: http://mail.python.org/mailman/options/web-sig/lists%40nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: PEP 444 (aka Web3)

Armin Ronacher
In reply to this post by PJ Eby
Hi,

On 2010-09-16 2:05 AM, P.J. Eby wrote:
> The first thing I notice is that web3.async appears to force all
> existing middleware to delete it from the environment if it wishes to
> remain compatible, unless it adapts to support receiving callables itself.
In terms of backwards compatibility, we have a huge change here anyways,
so existing middlewares are not that much of an issue I support.  I know
however that web3.async will be a controversial topic.

The reason it's in there is that there is theoretical support for async
frameworks on top of WSGI to have some kind of basic interoperability.

Someone brought up the argument that it relies on polling, but that is
only partially true because you control the incoming web3 environment.
That environment might contain some callbacks that the application can
use that would internally send signals to the server so that it knows
when to call the response callable.

The callback was modeled after the hack that nginx (if I remember
correctly) is doing wrt yielding empty strings until responses are ready.

I would like bring some people from asynchronous servers onto the
discussion for that particular issue before we decide on the future.
Tornado is currently the most popular Python project on github, so there
is genuine interest in async servers and I am pretty sure enough people
use it in practice.  This however also means that Tornado has its own
environment which looks very much like the situation we were in before
WSGI was around.

> On further reading I see you have something about middleware disabling
> itself if it doesn't support async execution, but this doesn't make any
> sense to me: if it can't support async execution, why wouldn't it just
> delete web3.async from the environ, forcing its wrapped app to be
> synchronous instead?
Instead of deleting it would set it to False though.  Why would it want
to disable itself?  For instance because the middleware is actually
depending on an asynchronous specification developed on top of web3 that
is not supported by synchronous servers which is the main intention of
that async flag.  To be used as the basis for an actual proper async
specification written by people that actually use async servers unlike
me and Chris :)

> My main fear with this spec is that people will assume they can just
> make a few superficial changes to run WSGI code on it, when in fact it
> is deeply incompatible where middleware is concerned. In fact, AFAICT,
> it seems like it will be *harder* to write correct web3 middleware than
> it is to write correct WSGI middleware now.
For just rewriting the environment it's about as complicated, and for
making middlewares harder that modify the response I think this is a
good thing.  Things middleware should do currently and do not:

- honour content-encoding
- correct set/unset content-length
- update/remove etags
- not be surprised by HEAD responses
- patching through exc_info
- not swallowing the write callable

I am sure there are more, I remember that Graham had some bad
experiences with them in particular.

> This seems like a step backward, since the whole idea behind dropping
> start_response() was to make correct middleware *easier* to write.
Do we really need middlewares that rewrite the response?  Even without
web3.async and limited to bytes only, there are so many things that can
go wrong and will go wrong.  I would instead suggest a common library
that people could use to develop middlewares on top of web3 that sorts
these things out for you.


Regards,
Armin
_______________________________________________
Web-SIG mailing list
[hidden email]
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe: http://mail.python.org/mailman/options/web-sig/lists%40nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: PEP 444 (aka Web3)

James Mills-3
On Thu, Sep 16, 2010 at 10:43 AM, Armin Ronacher
<[hidden email]> wrote:
> I would like bring some people from asynchronous servers onto the discussion
> for that particular issue before we decide on the future. Tornado is
> currently the most popular Python project on github, so there is genuine
> interest in async servers and I am pretty sure enough people use it in
> practice.  This however also means that Tornado has its own environment
> which looks very much like the situation we were in before WSGI was around.

As a developer of an asynchronous framework myself, I'm actually not
really sure what to think of
the whole web3.async "thing" yet... My feeling(s) are that other web
frameworks are just doing to
do their own thing anyway...

cheers
james


--
-- James Mills
--
-- "Problems are solved by method"
_______________________________________________
Web-SIG mailing list
[hidden email]
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe: http://mail.python.org/mailman/options/web-sig/lists%40nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: PEP 444 (aka Web3)

Armin Ronacher
Hi,

On 2010-09-16 3:33 AM, James Mills wrote:
> As a developer of an asynchronous framework myself, I'm actually not
> really sure what to think of
> the whole web3.async "thing" yet... My feeling(s) are that other web
> frameworks are just doing to
> do their own thing anyway...
Any chances of finding some common ground?


Regards,
Armin
_______________________________________________
Web-SIG mailing list
[hidden email]
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe: http://mail.python.org/mailman/options/web-sig/lists%40nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: PEP 444 (aka Web3)

James Mills-3
On Thu, Sep 16, 2010 at 11:42 AM, Armin Ronacher
<[hidden email]> wrote:
> Any chances of finding some common ground?

Well take Twisted for example. It's not specifically an asynchronous
web server is it ?
Whereas Tornado was specifically designed to be so.

I don't see how making WSGI Middlware "async aware" (if that's a good
way of looking at it)
has any benefit IHMO.

cheers
James

--
-- James Mills
--
-- "Problems are solved by method"
_______________________________________________
Web-SIG mailing list
[hidden email]
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe: http://mail.python.org/mailman/options/web-sig/lists%40nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: PEP 444 (aka Web3)

Roberto De Ioris
In reply to this post by Chris McDonough

> A PEP was submitted and accepted today for a WSGI successor protocol
> named Web3:
>
> http://python.org/dev/peps/pep-0444/
>
> I'd encourage other folks to suggest improvements to that spec or to
> submit a competing spec, so we can get WSGI-on-Python3 settled soon.
>
> - C
>
>

I generally like it.

About the *.file_wrapper removal, i suggest
a PSGI-like approach where 'body' can contains a File Object.

def file_app(environ):
    fd = open('/tmp/pippo.txt', 'r')
    status = b'200 OK'
    headers = [(b'Content-type', b'text/plain')]
    body = fd
    return body, status, headers


or

def file_app(environ):
    fd = open('/tmp/pippo.txt', 'r')
    status = b'200 OK'
    headers = [(b'Content-type', b'text/plain')]
    body = [b'Header', fd, b'Footer']
    return body, status, headers


(and what about returning multiple File objects ?)

By the way, congratulations for the big step forward

--
Roberto De Ioris
http://unbit.it

_______________________________________________
Web-SIG mailing list
[hidden email]
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe: http://mail.python.org/mailman/options/web-sig/lists%40nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: PEP 444 (aka Web3)

Gary Poster-3
In reply to this post by James Mills-3

On Sep 16, 2010, at 2:34 AM, James Mills wrote:

> On Thu, Sep 16, 2010 at 10:15 AM, Chris McDonough <[hidden email]> wrote:

Thank you for the work, Chris.

>> We can ditch everything concerning web3.async as far as I'm concerned.
>> Ian has told me that this feature won't be liked by the async people
>> anyway, as it doesnt have a trigger mechanism.
>
> You and Ian are right about that. I don't see the point of introducing
> an "async" property/variable into the environment data.

I've been hoping for something like web3.async.

When I saw it in the spec, I didn't see it as a way to support asynchronous applications generally.  I suspect that fully async applications are just not really ultimately interested in a wsgi/web3 world--the threaded model is too different.  I'd love to be wrong.  (To be clear, happily some async frameworks *are* interested in being wsgi servers.)

In any case, I saw it as a way for web3 threaded applications to support long polls, from JS or some other client.

Threaded applications might authenticate and do X work, and then pass off some work significantly more appropriate for an async server back to the web3 server.  That work might be proxying a file found elsewhere on an internal network; or waiting for a response from an asynchronous job in this process (Twisted) or some other one (RabbitMQ); or other similar tasks.  Meanwhile, the threaded application could go off and handle more requests, having done what was needed of it.

Periodically polling the callable wasn't what I was thinking of--I had the Twisted world in mind, so I was thinking more of a Deferred type model--but polling would be good enough for my needs.

I'd like to see it, or something like it.  If not, I suspect I'll be trying to hack something like this in somehow, because it addresses concerns we've had at Launchpad in recent planning sessions.  I'd *much* prefer to have a supported, clean approach.

Gary
_______________________________________________
Web-SIG mailing list
[hidden email]
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe: http://mail.python.org/mailman/options/web-sig/lists%40nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: PEP 444 (aka Web3)

Masklinn
In reply to this post by Chris McDonough
> I generally like it.
>
> About the *.file_wrapper removal, i suggest
> a PSGI-like approach where 'body' can contains a File Object.
>
> def file_app(environ):
>    fd = open('/tmp/pippo.txt', 'r')
>    status = b'200 OK'
>    headers = [(b'Content-type', b'text/plain')]
>    body = fd
>    return body, status, headers
>
As far as I understand it, `body` is an iterable so there should not be any problem with sending a file through directly in this manner. Better, the web3 spec specifically mandates that if the `body` iterable has a `close` method it must be called on request completion (second-to-last paragraph in the specification details section [0]). So a File Object as a body is already completely handled by web3.

On the other hand, `body` has to yield bytes, so `fd = open('/tmp/pippo.txt', 'rb')` I think.

> def file_app(environ):
>    fd = open('/tmp/pippo.txt', 'r')
>    status = b'200 OK'
>    headers = [(b'Content-type', b'text/plain')]
>    body = [b'Header', fd, b'Footer']
>    return body, status, headers
>
>
> (and what about returning multiple File objects ?)
>
Well you could just use `itertools.chain([b'Header'], fd, [b'Footer'])` and `itertools.chain(*files)` respectively though there is the issue that, with non-refcounting GCs (Jython, IronPython, pypy), these may stay unclosed for quite some time. A good idea would probably be some kind of `closingchain` replacement to `itertools.chain` which would be able to `close()` its sub-iterables if they're closable (or maybe a `contextchain` which calls `__enter__` and `__exit__` on its sub-iterables if those are available).

[0] http://python.org/dev/peps/pep-0444/#specification-details
_______________________________________________
Web-SIG mailing list
[hidden email]
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe: http://mail.python.org/mailman/options/web-sig/lists%40nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: PEP 444 (aka Web3)

Roberto De Ioris

Il giorno 16/set/2010, alle ore 08.37, Masklinn ha scritto:

>> I generally like it.
>>
>> About the *.file_wrapper removal, i suggest
>> a PSGI-like approach where 'body' can contains a File Object.
>>
>> def file_app(environ):
>>   fd = open('/tmp/pippo.txt', 'r')
>>   status = b'200 OK'
>>   headers = [(b'Content-type', b'text/plain')]
>>   body = fd
>>   return body, status, headers
>>
> As far as I understand it, `body` is an iterable so there should not be any problem with sending a file through directly in this manner. Better, the web3 spec specifically mandates that if the `body` iterable has a `close` method it must be called on request completion (second-to-last paragraph in the specification details section [0]). So a File Object as a body is already completely handled by web3.
>
> On the other hand, `body` has to yield bytes, so `fd = open('/tmp/pippo.txt', 'rb')` I think.
>


In this case i do not see a need for wsgi.file_wrapper replacement.

The Web3 gateway/hosting system can manage File-Like Object the way it wants
(and transparently for the application)

--
Roberto De Ioris
http://unbit.it
JID: [hidden email]

_______________________________________________
Web-SIG mailing list
[hidden email]
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe: http://mail.python.org/mailman/options/web-sig/lists%40nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: PEP 444 (aka Web3)

Dirkjan Ochtman
In reply to this post by Chris McDonough
On Thu, Sep 16, 2010 at 01:03, Chris McDonough <[hidden email]> wrote:
> A PEP was submitted and accepted today for a WSGI successor protocol
> named Web3:
>
> http://python.org/dev/peps/pep-0444/
>
> I'd encourage other folks to suggest improvements to that spec or to
> submit a competing spec, so we can get WSGI-on-Python3 settled soon.

I find the order of the application return arguments really annoying,
could it just be status, headers, body? Mirrors the actual structure
of the request, which is easier to remember IMO.

Also, I would really like it if the header value returned by
applications must be checked for an .items() method so we can return
(o)dicts in addition to tuples.

I also keep thinking that some things (for example status) should just
be allowed to be text, but restricted to ascii.

Cheers,

Dirkjan
_______________________________________________
Web-SIG mailing list
[hidden email]
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe: http://mail.python.org/mailman/options/web-sig/lists%40nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: PEP 444 (aka Web3)

Armin Ronacher
Hi,

On 9/16/10 1:23 PM, Dirkjan Ochtman wrote:
> I find the order of the application return arguments really annoying,
> could it just be status, headers, body? Mirrors the actual structure
> of the request, which is easier to remember IMO.
The motivation is that you can pass that to constructors of response
objects already in place.

response_tuple = response.get_response_tuple()
response = Response(*response_tuple)

The order "body", "status code", "headers" is what Werkzeug and WebOb
are currently using.  Django has (content, mimetype, status) as
constructor but if they detect a list/dict on the third parameter they
could assume that mimetype referes to the status thus they have a proper
upgrade path.

> Also, I would really like it if the header value returned by
> applications must be checked for an .items() method so we can return
> (o)dicts in addition to tuples.
That would be a nice to have, but makes the middleware logic harder
because each middleware would have to check for the type.

> I also keep thinking that some things (for example status) should just
> be allowed to be text, but restricted to ascii.
Works for 2.x, but on 3.x that would mean each middleware would have to
check the type before each operation and convert to bytes if necessary
which means a lot of overhead for each middleware in the stack.


Regards,
Armin
_______________________________________________
Web-SIG mailing list
[hidden email]
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe: http://mail.python.org/mailman/options/web-sig/lists%40nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: PEP 444 (aka Web3)

Tarek Ziadé
In reply to this post by Chris McDonough
On Thu, Sep 16, 2010 at 1:03 AM, Chris McDonough <[hidden email]> wrote:
> A PEP was submitted and accepted today for a WSGI successor protocol
> named Web3:
>
> http://python.org/dev/peps/pep-0444/
>
> I'd encourage other folks to suggest improvements to that spec or to
> submit a competing spec, so we can get WSGI-on-Python3 settled soon.

I have a request for the middleware stack. There should be one obvious
way to get back to the original application, through the stack

Right now, I have to write crazy things like this depending on the stack:

  original_app = self.app.app.application.app

Because some middleware use "app", some "application" etc..

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.

Thanks
Tarek


--
Tarek Ziadé | http://ziade.org
_______________________________________________
Web-SIG mailing list
[hidden email]
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe: http://mail.python.org/mailman/options/web-sig/lists%40nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: PEP 444 (aka Web3)

Dirkjan Ochtman
In reply to this post by Armin Ronacher
On Thu, Sep 16, 2010 at 13:32, Armin Ronacher
<[hidden email]> wrote:

> The motivation is that you can pass that to constructors of response objects
> already in place.
>
> response_tuple = response.get_response_tuple()
> response = Response(*response_tuple)
>
> The order "body", "status code", "headers" is what Werkzeug and WebOb are
> currently using.  Django has (content, mimetype, status) as constructor but
> if they detect a list/dict on the third parameter they could assume that
> mimetype referes to the status thus they have a proper upgrade path.

Okay, I can see why the order makes sense from a default arguments
point of view, but I'm still not sure why it helps if the Response()
signature looks like the application return signature.

> That would be a nice to have, but makes the middleware logic harder because
> each middleware would have to check for the type.
>
> Works for 2.x, but on 3.x that would mean each middleware would have to
> check the type before each operation and convert to bytes if necessary which
> means a lot of overhead for each middleware in the stack.

Okay, I guess it makes sense. I just thoroughly dislike that we're
making applications harder in a bunch of places to make the life of
middleware easier. Surely we write more applications than middleware?
Can we somehow invert the model to have the gateway act as a
controller for middleware, so that we can canonicalize application
returns before passing them to the middleware? Or provide a function
in wsgiref that allows me to write an application like this:

import wsgiref

def app(environ):
     return wsgiref.canonicalize(200, {'Content-Type': 'text/plain'}, ['foo'])

Maybe it should be an exceedingly light-weight response class (which
could be inherited by the frameworks) instead.

Cheers,

Dirkjan
_______________________________________________
Web-SIG mailing list
[hidden email]
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe: http://mail.python.org/mailman/options/web-sig/lists%40nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: PEP 444 (aka Web3)

Armin Ronacher
In reply to this post by Tarek Ziadé
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?


Regards,
Armin
_______________________________________________
Web-SIG mailing list
[hidden email]
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe: http://mail.python.org/mailman/options/web-sig/lists%40nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: PEP 444 (aka Web3)

Tarek Ziadé
On Thu, Sep 16, 2010 at 1:57 PM, Armin Ronacher
<[hidden email]> 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
[hidden email]
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe: http://mail.python.org/mailman/options/web-sig/lists%40nabble.com
12345