From pje at telecommunity.com  Mon Feb  1 20:44:27 2016
From: pje at telecommunity.com (PJ Eby)
Date: Mon, 1 Feb 2016 20:44:27 -0500
Subject: [Web-SIG] Fwd: Collating follow-up on the future of WSGI
In-Reply-To: <CAFwN1upZEicUOkeqPAUZq5F5vgFy=R40gYNRDVswqZwqLBN3Pw@mail.gmail.com>
References: <71B64498-C7AA-493D-BB9B-74264A145A11@lukasa.co.uk>
 <CAJ3HoZ1Me53N76ec01m2b8UYDVVGpzCBd775Y9rVxzgXuoR1wQ@mail.gmail.com>
 <CAJNb-9oQWAKyNHyn_ygxb8gspgJW_2hQNyQ4cL9HdMV8Bp4x7w@mail.gmail.com>
 <CAJ3HoZ32hDE9H-np1ZScYT5TO8L+TtJywAfAgBO9bubyPehDEg@mail.gmail.com>
 <CAJNb-9qz71v01ZS4p5AXYbjYy-1dsGc=-SGzGYSoaiHc_dOaSA@mail.gmail.com>
 <1B5EC8D5-A2B1-499A-ADE3-B969EC6851A6@gmail.com>
 <CAJNb-9r7Wxb3xb76E1DyajuBBwCPfKGArqQMA8yP0yf0J=BzEw@mail.gmail.com>
 <45B5DFE8-7951-4B21-9EEA-B30A61BB3908@gmail.com>
 <CAJNb-9qCQm2C7coa5hG3AyTA6QwHT0=L4p0nQtxYEwLgMP1wBQ@mail.gmail.com>
 <CAJNb-9rwkppcYrXRmdT7djdaCS1N10L+J_BRzskfKy=Er4c_2Q@mail.gmail.com>
 <CALeMXf4oXYo8E3_duOBStTw_BNVFAn2JcUiKyb7RD1qYdaxOkQ@mail.gmail.com>
 <CAFwN1upZEicUOkeqPAUZq5F5vgFy=R40gYNRDVswqZwqLBN3Pw@mail.gmail.com>
Message-ID: <CALeMXf6eia2-6B7TOO8pmc_XPWuA44fvvXvXPGp7O1FCLWE78A@mail.gmail.com>

On Sun, Jan 31, 2016 at 8:57 PM, Andrew Godwin <andrew at aeracode.org> wrote:
> The idea of a standardised protocol escape is indeed interesting, though I'm
> not so keen on the idea of making triply nested functions a requirement for
> something like this.

It's not a requirement; the exact spelling of any handlers or
protocols is up to the escaped-to protocol.  (It could expect a class,
for example, a generator, or an async function.)


> How would you see this interacting with potential asynchronous
> frameworks/reactors? The WebOb example only reacts to events also coming
> from within a WebSocket abstraction, but what if I wanted to e.g. send a
> message on database save? How would my application manage to trigger the
> WebSocket, in another thread or process, to do that?

The overall structure of this approach is that it's a way to do
arbitrary things at the "end" of a standard WSGI request/response
cycle, provided that the special response hasn't been tampered with by
middleware on the way out.  I don't know what you mean by "send a
message on database save" so it's hard to give particulars.  But
basically, the escape mechanism doesn't restrict the escaped-to
protocol in any way, except to the extent that it's affected by the
request side of things.  For example, you can only asynchronously read
the wsgi.input if it hasn't been read at the time the escape message
is received by the origin/gateway server.  Reading request headers via
the extended API might break routing middleware, and so on.  However,
as regards the "response", the escape mechanism should be fully
general, whether the target API is sync or async.

From cory at lukasa.co.uk  Wed Feb 17 06:51:18 2016
From: cory at lukasa.co.uk (Cory Benfield)
Date: Wed, 17 Feb 2016 11:51:18 +0000
Subject: [Web-SIG] Changes for WSGI 1.1
Message-ID: <BCFA3775-A4A8-4755-9C2E-3AC39030F5CE@lukasa.co.uk>

All,

After having had a fairly useful discussion with you all over the past few weeks, I?ve begun working on the next draft of the WSGI PEP, WSGI 1.1. This work is being tracked in a GitHub repository[0]. Currently, I?ve made a few changes directly on the master branch that I believe are editorial[1]: updating references and making linguistic changes.

So far, almost all non-editorial changes that have been proposed in this list I?ve made on branches and opened GitHub Pull Requests for. You can find these proposals here[2]. At this time, I?d like to call for people on this list who care to please offer their review on these proposed changes. You can view the changes by clicking into the specific pull request and evaluating the diff. The pull request should also include a short rationale for the change, or a description of it at the very least.

I?d also like to welcome others to propose changes that I have not yet drafted, or to propose changes to my drafts. Please use the standard GitHub Pull Request flow if you are happy with that model: if not, I?ll also accept emailed patches.

Please let me know what you think!

Cory

[0]: https://github.com/python-web-sig/wsgi-1.1
[1]: https://github.com/python-web-sig/wsgi-1.1/commits/master
[2]: https://github.com/python-web-sig/wsgi-1.1/pulls
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mail.python.org/pipermail/web-sig/attachments/20160217/5d8e918a/attachment.sig>

From dirkjan at ochtman.nl  Wed Feb 17 07:55:34 2016
From: dirkjan at ochtman.nl (Dirkjan Ochtman)
Date: Wed, 17 Feb 2016 13:55:34 +0100
Subject: [Web-SIG] Changes for WSGI 1.1
In-Reply-To: <BCFA3775-A4A8-4755-9C2E-3AC39030F5CE@lukasa.co.uk>
References: <BCFA3775-A4A8-4755-9C2E-3AC39030F5CE@lukasa.co.uk>
Message-ID: <CAKmKYaAdiysndU4pyOWho1AKkkU_w=TsxWwHOpYQn0OECAPyiA@mail.gmail.com>

On Wed, Feb 17, 2016 at 12:51 PM, Cory Benfield <cory at lukasa.co.uk> wrote:
> Please let me know what you think!

I reviewed all the pull requests and they look good to me, save one
tiny nit that I left a comment for.

Cheers,

Dirkjan

From cory at lukasa.co.uk  Thu Feb 18 03:05:41 2016
From: cory at lukasa.co.uk (Cory Benfield)
Date: Thu, 18 Feb 2016 08:05:41 +0000
Subject: [Web-SIG] Changes for WSGI 1.1
In-Reply-To: <CAKdhhwETHtqxd2zJ-XmX8mFOSCCwhoi0iMCL3txB3jqoyiTWpA@mail.gmail.com>
References: <BCFA3775-A4A8-4755-9C2E-3AC39030F5CE@lukasa.co.uk>
 <CAKmKYaAdiysndU4pyOWho1AKkkU_w=TsxWwHOpYQn0OECAPyiA@mail.gmail.com>
 <CAKdhhwETHtqxd2zJ-XmX8mFOSCCwhoi0iMCL3txB3jqoyiTWpA@mail.gmail.com>
Message-ID: <BEFD08B2-7CFE-4114-8B31-70B2C9D9AF97@lukasa.co.uk>

Yeah, the directionality needs to be specified more clearly here. Thanks!

Cory

> On 17 Feb 2016, at 17:55, Michael Merickel <mmericke at gmail.com> wrote:
> 
> I'm not sure the "backward-incompatible" text in your proposal makes sense. I think you actually mean to say that applications written to use new WSGI 1.1 features will not work with WSGI 1.0 servers. That's obvious though by the version number bump. I'd be very concerned, however, if my application using only WSGI 1.0 features didn't work on a WSGI 1.1 server (which is what I thought you were saying the first time I saw backward-incompatible in the text).
> 
> On Wed, Feb 17, 2016 at 6:55 AM, Dirkjan Ochtman <dirkjan at ochtman.nl <mailto:dirkjan at ochtman.nl>> wrote:
> On Wed, Feb 17, 2016 at 12:51 PM, Cory Benfield <cory at lukasa.co.uk <mailto:cory at lukasa.co.uk>> wrote:
> > Please let me know what you think!
> 
> I reviewed all the pull requests and they look good to me, save one
> tiny nit that I left a comment for.
> 
> Cheers,
> 
> Dirkjan
> _______________________________________________
> Web-SIG mailing list
> Web-SIG at python.org <mailto:Web-SIG at python.org>
> Web SIG: http://www.python.org/sigs/web-sig <http://www.python.org/sigs/web-sig>
> Unsubscribe: https://mail.python.org/mailman/options/web-sig/mmericke%2Bwebsig%40gmail.com <https://mail.python.org/mailman/options/web-sig/mmericke%2Bwebsig%40gmail.com>
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/web-sig/attachments/20160218/c9f54ace/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mail.python.org/pipermail/web-sig/attachments/20160218/c9f54ace/attachment.sig>