<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Oct 10, 2014 at 9:10 PM, PJ Eby <span dir="ltr"><<a href="mailto:pje@telecommunity.com" target="_blank">pje@telecommunity.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Fri, Oct 10, 2014 at 8:56 AM, Graham Dumpleton<br>
<<a href="mailto:graham.dumpleton@gmail.com">graham.dumpleton@gmail.com</a>> wrote:<br>
> So PJE, please step back and do not go rushing out to create a PEP. That is<br>
> the worst thing you could do at this point and will only serve to deter<br>
> people from the community contributing and so stifle proper discussion about<br>
> this whole topic.<br>
<br>
</span>Huh?  Have you *read* the PEP?  The entire point of it is to provide a<br>
basis for *experimenting* with new standards, not to "stifle<br>
discussion" of them.  It's not even an *API*, for heavens' sake.  It's<br>
just a description of how to upgrade to new standards from within<br>
existing WSGI frameworks, without needing to tunnel responses and<br>
without breaking subrequest middleware.<br>
<br>
IOW, it's a WSGI *1.0* server extension protocol, and a fairly *minor*<br>
one at that.  (Indeed, it's little more than an enhanced variation of<br>
wsgi.file_wrapper!)  It's not any sort of competitor or alternative to<br>
what Robert's working on; it's a *stepping stone* for what Robert's<br>
working on.<br>
<br>
In early discussion with Robert -- both here and on github -- it<br>
became apparent to me that restricting post-WSGI specifications to<br>
what can be achieved in WSGI 1 tunneling is a bad idea.  So I've<br>
created a *bridging* specification, that allows post-WSGI APIs to be<br>
accessed from within WSGI-based apps and frameworks.<br>
<br>
That's *all*.<br>
<br>
All of the things you've mentioned as being in scope for discussion,<br>
are *still* in scope for discussion.  All *this* proposal does is show<br>
how those things could be *accessed*, *today*, from inside existing<br>
web apps and frameworks, once those new APIs exist.<br>
<span class=""><br>
<br>
> You have no more experience or mandate to be specifying a<br>
> standard for this than anyone else.<br>
<br>
</span>If by "this" you're referring to HTTP/2 or some other new post-WSGI<br>
API, then I agree with you.  But that's not what the PEP is about.<br>
<span class=""><br>
<br>
>  By creating a PEP though that gets<br>
> perceived by many as meaning the discussion is over. This is exactly what<br>
> you did for PEP 3333 and which caused previous discussion about improving<br>
> WSGI to get shutdown.<br>
<br>
</span>That's an interesting perspective, but I don't see how it can be<br>
reconciled with the facts.<br>
<br>
First off, I didn't write a new PEP; I wrote up some of *your*<br>
proposed clarifications for Python 3 as WSGI 1.0.1, which was intended<br>
to add new clarifying text to PEP 333, *not* to create a new PEP.  It<br>
was *Guido* who said it must be a new PEP, as you will see here:<br>
<br>
  <a href="https://mail.python.org/pipermail/web-sig/2010-September/004691.html" target="_blank">https://mail.python.org/pipermail/web-sig/2010-September/004691.html</a><br>
<br>
and here (where he even says, "Don't see this as a new spec. See it as<br>
a procedural issue."):<br>
<br>
  <a href="https://mail.python.org/pipermail/web-sig/2010-September/004694.html" target="_blank">https://mail.python.org/pipermail/web-sig/2010-September/004694.html</a><br>
<br>
Second, I didn't make anybody stop discussing alternatives for moving<br>
things forward.  Nobody *ever* said to stop working on a version 2 or<br>
even 1.1, certainly not me.  See for example, this message, where I<br>
agreed with Ian's POV that there was room for both PEP 333 fixes *and*<br>
continued work on PEP 444:<br>
<br>
  <a href="https://mail.python.org/pipermail/web-sig/2010-September/004662.html" target="_blank">https://mail.python.org/pipermail/web-sig/2010-September/004662.html</a><br>
<br>
Third, and finally, as far as I can tell from the record of the<br>
discussion back then, it was you -- and *only* you -- who suggested<br>
that the acceptance of PEP 3333 meant the discussion was *over*.<br>
Indeed, on your blog you actually pushed back at Alice for bringing up<br>
more PEP 444 discussion!<br>
<br>
Nonetheless, discussion of PEP 444 and async APIs and such proceeded<br>
well past the introduction of PEP 3333, even without its original<br>
authors' participation.  And, ironically enough, your posts show up in<br>
that discussion, bemoaning that Alice (the new PEP 444 champion) was<br>
creating confusion by calling that proposal WSGI 2.0!<br>
<span class=""><br>
<br>
> The result was that the only thing that really got<br>
> addressed in PEP 3333 was Python 3 compatibility and a lot of the other bits<br>
> of the WSGI specification which are poorly defined, contradictory or<br>
> restrictive and which cause WSGI server and application developers pain<br>
> never got addressed. If that prior discussion hadn't been shutdown in that<br>
> way, we could have been using a better defined and improved WSGI years ago<br>
> already.<br>
<br>
</span>Those things didn't get addressed because *you* didn't take up the<br>
lead -- a lead which I more than once mentioned you should take up.<br>
For example, as I said in<br>
<a href="https://mail.python.org/pipermail/web-sig/2010-September/004693.html" target="_blank">https://mail.python.org/pipermail/web-sig/2010-September/004693.html</a> :<br>
<br>
> The full list of things Graham and others have asked for or<br>
> recommended would indeed require a 1.1 version at minimum, and thus a<br>
> new PEP.  But I really don't want to start down that road right now,<br>
> and therefore hope that I can talk Graham or some other poor soul<br>
> into shepherding a 1.1 PEP instead.  ;-)<br>
<br>
You didn't, and haven't, taken up that slack.  What you've<br>
consistently done is mutter and grumble on the sidelines about how<br>
it's never going to happen and disclaim any responsibility for<br>
actually writing a proposal because it's never going to go anywhere --<br>
thereby *ensuring* that it's never going to go anywhere.  (And one key<br>
reason I wrote the WSGI-RUB PEP is that I noticed I'd started doing<br>
what *you* do: grumbling at Robert about his proposals, without taking<br>
the time to write up my own, dumping the hard work on him instead of<br>
getting my own hands dirty.)<br>
<br>
PEPs don't magically arise from some mysterious group consensus.  They<br>
happen because some poor shmuck does the work of *building* a<br>
consensus around something they want to have happen, hammering out<br>
agreements, and writing the thing up.  The only way the improvements<br>
you want are ever going to happen are if you either lead the process<br>
yourself, or get somebody else to do it for you.  If you want to ride<br>
Robert's back and get him to do the dirty work, that's A-OK by me.  I<br>
don't have a horse in *that* race, and haven't for *ten years*.<br>
<br>
The PEP 444 discussion didn't stop because I did the dirty work of<br>
turning some of your gripes into concrete specifications.  It stopped<br>
because the poor schmucks who initially volunteered to do the heavy<br>
lifting on PEP 444 were only doing it to get Python 3 sorted out, and<br>
were sufficiently happy with the 1.0.1 clarifications to be glad of<br>
dropping the *workload* involved...  a workload which you declined to<br>
pick up, despite many people (myself included) *asking* for continued<br>
discussion of PEP 444.<br>
<br>
*PEPs* don't stifle discussions.  *Lack of volunteers* stifles<br>
discussions.  Without somebody driving the process, discussions about<br>
multiple substantive issues with a PEP tend to die a natural death as<br>
everybody voices their opinion *once*...  and then shuts up.<br>
<br>
What keeps a PEP moving is somebody taking those raw opinions and<br>
pushing something forward from them, asking "so what about this, then?<br>
 Will this work?  What do you think of that?"  Without that energy<br>
being put *in*, nothing comes back out, except maybe the occasional<br>
lengthy session of bikeshedding on the non-substantive parts of a<br>
proposal.  Indeed, the more substantive the discussion, the fewer the<br>
participants, and the harder it is to actually get things moving...<br>
and the more likely the champion is to give up in the face of what<br>
seems like overwhelming opposition.<br>
<br>
So it's not suprising that Chris and Armin and Alice all gave up on<br>
doing that: it's a lot of hard work, and *I'm* not volunteering for<br>
it, either.<br>
<br>
If you want Robert to do the work of shepherding a new post-WSGI PEP<br>
under your guidance I am *all* in favor of it.  I've been trying to<br>
get *you* off the sidelines on this thing for *years*.  Indeed, if<br>
that is the only outcome of the work I did on the new RUB proposal,<br>
then I am as happy to drop out of it as Chris and Armin were to drop<br>
PEP 444.  (Frankly, some of my admonishments to Robert were based on<br>
my expectation that you would continue to snipe from the sidelines and<br>
avoid getting your hands dirty.)<br>
<br>
Which is unfortunate, because AFAIK and IMO, *you* are the only person<br>
currently active in the community who's both *actually* qualified to<br>
ride herd on WSGI 1.1 *and* is an absolute "must-have" contributor for<br>
the sucess of any true post-WSGI specification.  (Again, AFAIK and<br>
IMO, not intended as a slight to anybody else whose qualifications and<br>
contributions I'm presently unaware of.)<br>
<br>
So the PEP I've written *isn't* an attempt to make such a post-WSGI<br>
specification.  It's my attempt to build a bridge from the WSGI we<br>
have, to whatever specification you and the rest of the Web-SIG come<br>
up with *next*.  Indeed, it's intended as something of a "parting<br>
gift", to address the development, deployment, and long-term migration<br>
issues that *any* post-WSGI spec will have.<br>
<br>
I'm tired of dealing with WSGI's limitations and corner cases and<br>
quirks, and I don't want to have to spend a lot of time reviewing<br>
post-WSGI specs to check for breakage on those quirks.  The point of<br>
the RUB is to set the post-WSGI world entirely free of them, and it's<br>
my gift to you and Robert and anybody else who wants to clean away the<br>
mess and start over.<br>
<br>
With it, you can imagine completely new APIs (like the generator-based<br>
ones Robert was sketching), without needing to figure out how to make<br>
the bloody thing work with WSGI 1.0 middleware.<br>
<br>
Pre-empting that kind of free API design is the *last* thing I want to<br>
have happen, which is precisely *why* I've put forward the RUB spec.<br>
I don't *want* to spend a lot of time telling Robert all the things he<br>
*can't* do, because of WSGI 1's limitations.<br>
<br>
So instead, I've proposed something that will let him "have" whatever<br>
sort of post-WSGI cake he wants, while still letting WSGI 1 code "eat"<br>
it too.<br>
<span class=""><br>
<br>
> Right now, that you have created your own separate space<br>
<br>
</span>How is a Web-SIG thread a "separate space", let alone my "own" separate space?<br>
<span class=""><br>
<br>
> for writing up a specification which you are now<br>
> trying to rush into a PEP comes across as you not really wanting to<br>
> co-ordinate with Robert on this as a community effort with it instead<br>
> appearing that you think you know better than anyone else and nothing anyone<br>
> else says will be of value. In the face of that, it is hardly surprising<br>
> that no one has really responded to what you have proposed.<br>
<br>
</span>Well, if that's the case, it's certainly an unfortunate<br>
misunderstanding.  Because all I have *actually* done is described a<br>
way that *everyone* can contribute to the development of new APIs,<br>
without *first* needing everyone *else* to agree on those APIs and<br>
modify their web frameworks to support them.  I'm trying to make it<br>
possible for there to be *more* participation, not less.  Any J.<br>
Random Developer with an idea or an itch to scratch should be able to<br>
throw together an implementation of a post-WSGI API, and start using<br>
it today from inside existing WSGI frameworks.  It's from just such<br>
experiments that de facto -- and later, de jure -- standards can and<br>
should arise.<br>
<br>
Personally, I don't expect there to be much discussion of my proposal<br>
right now because nobody is yet trying to *implement* any post-WSGI<br>
specifications.  The RUB spec is mostly a stake in the ground, to say,<br>
"Don't worry about WSGI 1 compatibility or tunneling; you can use any<br>
API paradigm you want, and the community will still be able to make an<br>
orderly transition to using it.  Here's how."<br>
<br>
At this point, AFAIK, there are precisely two APIs that could have<br>
benefited from the prior existence of WSGI-RUB: nghttp2 and<br>
uwsgi.websockets.  (Which is why the examples in the spec are based on<br>
them.)  And I'm not especially aware of anybody else writing new ones,<br>
who would therefore be interested in it.  Frankly, I wrote the thing<br>
to get it out of my head and to have a convenient place to point to<br>
when anybody makes the same mistake I did, of trying to limit<br>
post-WSGI API design to what can be safely shoehorned back through<br>
WSGI 1 response middleware.<br>
<br>
I don't expect much *detailed* discussion of WSGI-RUB, in other words,<br>
until there's at least a strawman post-WSGI API proposal.  (Which,<br>
IIUC from his last message, Robert is doing some experimenting<br>
towards.)<br>
<br>
Perhaps it is not clear from your cursory review of the existing<br>
discussion, but both Robert and I *learned* some things from our<br>
interaction.  And one of the things that *I* learned from that<br>
interaction was that nitpicking from the sidelines about what Robert<br>
couldn't do or how he should do it was not productive.<br>
<br>
Which is why I've put forth a proposal that eliminates the need for<br>
post-WSGI APIs to be nitpicked for WSGI 1 middleware compatibility.<br>
<br>
And it's why I hope *you* will read that proposal, and have something<br>
to say about its substance, because you are one of the people from<br>
whom I have most eagerly awaited such feedback, be it good, bad, or<br>
ugly.<br>
<br>
But I would *much* prefer some feedback about its *substance*, to a<br>
bunch of insinuations about whether I should've proposed it at all.<br>
<div class="HOEnZb"><div class="h5">_______________________________________________<br>
Web-SIG mailing list<br>
<a href="mailto:Web-SIG@python.org">Web-SIG@python.org</a><br>
Web SIG: <a href="http://www.python.org/sigs/web-sig" target="_blank">http://www.python.org/sigs/web-sig</a><br>
Unsubscribe: <a href="https://mail.python.org/mailman/options/web-sig/bchesneau%40gmail.com" target="_blank">https://mail.python.org/mailman/options/web-sig/bchesneau%40gmail.com</a></div></div></blockquote><div><br></div><div><br></div><div>OK, </div><div><br></div><div>So I should probably know you, but I can't recollect right now what you do or write. Anyway I find it really disturbing the way you're actually acting and try to push your ideas based on private feedback coming from unknown or choosing who should be a reference. That certainly not the right way to have all actors on the table. Because if we go for a new WSGI spec, you certainly want it. And I am speaking as one of these actors.</div><div><br></div><div>In my opinion, if we want to go further we should first define what are the problem we want to solve, and then get the feedback from all the actors around:</div><div><br></div><div>- framweorks authors</div><div>- libraries author </div><div>- server authors</div><div><br></div><div>If you don't have all actors around and majors are missing, there is probably no point to continue. I do think the idea of having a repository to collect it with people arbitrating the discussions on them on the mailing is a good way to go further. Now I think we are still missing of a clear definition of the problem. This is from what we should start instead of starting by giving our philosophy on how the problem should be solved.</div><div><br></div><div>- benoit.</div></div><br></div></div>