[Web-SIG] Draft 2: WSGI Response Upgrade Bridging

[Graham Dumpleton]

On 07/10/2014, at 7:15 AM, PJ Eby <pje at telecommunity.com> wrote:

> As before, you can find a "living" HTML version of the draft in progress at:
> 
>   https://gist.github.com/pjeby/62e3892cd75257518eb0
> 
> (In addition to nice formatting, it also has a clickable table of contents.)
> 
> After the next round of feedback, I plan to convert this to reST and
> get a PEP number assigned -- assuming nobody comes up with a killer
> problem that sends me back to the drawing board, of course.  ;-)


For those who were not aware, I personally haven't commented as yet on this discussion because I have been on a holiday for the last few weeks and I wasn't going to allow a discussion about this to ruin my holiday. 

I haven't caught up yet on all the discussion, but it is sad to say that it has headed down a direction exactly as a I warned Robert Collins in private discussions would likely happen, with certain people trying to rush things to push their own specific idea for how things should be done, with the risk that that will dominate the agenda and so push Robert out of the way as far as trying to coordinate this as a community effort where anyone could feel confident about providing input with the result then also being a community effort.

So PJE, please step back and do not go rushing out to create a PEP. That is the worst thing you could do at this point and will only serve to deter people from the community contributing and so stifle proper discussion about this whole topic. You have no more experience or mandate to be specifying a standard for this than anyone else. By creating a PEP though that gets perceived by many as meaning the discussion is over. This is exactly what you did for PEP 3333 and which caused previous discussion about improving WSGI to get shutdown. The result was that the only thing that really got addressed in PEP 3333 was Python 3 compatibility and a lot of the other bits of the WSGI specification which are poorly defined, contradictory or restrictive and which cause WSGI server and application developers pain never got addressed. If that prior discussion hadn't been shutdown in that way, we could have been using a better defined and improved WSGI years ago already.

Robert has stuck his neck out to try and bring various parties together to work on this where anyone who has an opinion or idea can raise them so we as a community can all together come up with something which is workable for both server implementers and web application developers.

Robert even setup a github repo specifically as a place to bring together all those ideas and described how people can add stuff there. For whatever personal reason you have decided to ignore that repo Robert set up and decided to go alone. If you have an issue with the way the repo was structured which didn't make it easy for you to contribute your work into it, then work with Robert to address that. Right now, that you have created your own separate space for writing up a specification which you are now trying to rush into a PEP comes across as you not really wanting to co-ordinate with Robert on this as a community effort with it instead appearing that you think you know better than anyone else and nothing anyone else says will be of value. In the face of that, it is hardly surprising that no one has really responded to what you have proposed.

So slow down. This is not a race to see who can be the first to come out with a PEP and so dominate the discussion, it is meant to be a community effort.

Robert. What I would suggest you do is reboot this whole effort.

Go back and perhaps look at how the github repo you setup is structured and make it more obvious how anyone can add their work into it in separate areas of it as need be and not just as issues, if that isn't already clear enough. Document exactly what you want people to do as far as adding anything there. Find people who will work with you on making all this clearer and defining any process.

The next step is to make a more definite statement about the timeline for this whole discussion.

Specifically, give notice of a formal request for comment period and publicise it through any Python blogs of the PSF that might be able to be used, as well as through the different Python web communities. Also get prominent individuals in the Python WSGI and web community to also publicise the comment period.

Set a specific date for the end of that comment period. There should be no rush on this and people should be given adequate time to respond. Most interested parties would only do this in their spare time and employers aren't going to allow them to waste their work time on it. So make the comment period something like 2 months from the date of announcing it.

What can people comment on?

They may want to comment on the process itself of how we get to the various specifications that may come out of this.

They may want to comment on what should even be addressed in any revisions or extensions to the WSGI specification. In other words, don't limit this to just HTTP/2 and web sockets support. Allow people to raise their pet peeves about the existing WSGI specification so we can perhaps properly address them this time. The whole ASYNC issue with existing WSGI applications also should not be ruled out of scope as far as the comment period.

Finally and hopefully, rather than people just complaining about things or giving wish lists, they will present properly fleshed out ideas for how to concretely solve ideas around ASYNC, HTTP/2 and web sockets.

The point is that this should purely be a period for collecting information as was I believe your original intent. Make it easy for people to contribute, but defuse the idea that it is a competition or race played out on the WEB-SIG mailing list, to see who is better, and so take the heat out of the discussion by simply having people put their ideas in the github repo for later review in a followup step.

Make it absolutely clear that the intent is not for people to start pushing out PEPs as competing proposals. Such a path is only going to be detrimental to the long term success of all this and make people in the community feel that they are unable to participate because of the higher expectations of what has to go into a PEP.

At the end of the comment period would then come a period of review of what is submitted to better define the scope of what seems sensible as far as what can be tackled. Not every idea has to be addressed. Set a time line you would expect for that review to take place, but specifically say that how long it will take is going to be fuzzy as how that review is even to be run would have to be worked out first.

Then from that review, a scope of work can be specified and broken out into different working groups using any proposals by people submitted during the comment period as a basis.

Yes Robert, I understand that this is how you want things to work, but the structure and timeline has to be better specified as an overall process.

If you don't then you will keep getting people who think that they can ignore the process you want followed and set their own agenda.

Once the process is better defined, then we as a community can say, work within it, or go away.

Graham
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/web-sig/attachments/20141010/d58f36a1/attachment.html>