2009/9/21 P.J. Eby <p...@telecommunity.com>: > At 08:48 AM 9/20/2009 -0400, Etienne Robillard wrote: >> >> Good plan but I'm afraid now only a bunch of elite people on this list >> is going to remember all the details on theses "upcoming" >> specifications. Why the rush to specify WSGI 3.0 and not focus >> mainly on the next one ahead ? > > Because having more versions of the spec is a bug, not a feature. How many > versions will a server or framework be reasonably expected to support?
I think there is perhaps two aspects to the original question about why even project ahead to WSGI 3.0 (no start_response) at this point. The first is why we want to even be considering dropping start_response at all at this point if people see the current way of doing things as reasonable. The second is whether any effort in drafting a new specification can be avoided at all by going direct to WSGI 3.0, combining amendments, going unicode and dropping start_response all in one go. I have a few views on this. The first is that although I probably have the most difficult job to implement multiple WSGI versions, given that mod_wsgi is all in C code with no Python code at all, the changes we are talking about at the moment aren't that drastic that can't relatively easily support multiple WSGI versions. In fact, mod_wsgi already implements what we are talking about in WSGI 1.1. This is because WSGI 1.1 is more about providing guarantees to the WSGI application based on how the majority of WSGI adapters/servers already work. I would expect it will be even simpler for WSGI adapters/servers implemented in pure Python to cope with multiple versions. In respect of defining all the versions now as a well defined roadmap, from the adapter/server side, you need to realise that existing implementations have become quite stable. As such, the frequency of any updates to them is going to get larger and larger. For me, I would rather add in the support for WSGI 1.1/2.0/3.0 now, knowing that likely might not make another major version release of mod_wsgi for a year or more, if at all. If mod_wsgi is stable and ends up don't see a need to go and implement further new features I have speculated on, then I don't want to come back in a year just to add WSGI 3.0 support. Further, given that Python 3.X is going to be a trigger point for people to at least make changes to unicode, it would be nice to have WSGI 3.0 out there as a separate additional step they can consider at the same time. Ultimately I feel it will be the general masses and not WSGI adapter/server implementers who will make the decision about how big a jump they will want to make. Enforcing a jump to WSGI 3.0 may not be looked on favourably given that that is a much more significant change. Think of all the problems with migration to Python 3.X as far as people waiting for third party modules to be updated. You will see the same problem with WSGI components if we go direct to WSGI 3.0. As WSGI 2.0 for Python 2.X is, due to way bytes/unicode can still be used interchangeably, it is a much simpler transition and I can see a quick movement to that, or even for the WSGI components to work with all of WSGI 1.0/1.1/2.0 at the same time. For many, if they are smart about it, they may even be able to easily support WSGI 3.0 as well at same time as 1.0/1.1/2.0. The key here would probably be us defining prototype skeletons for code which exhibits how supporting multiple versions in WSGI components could be done easily. As to the idea that going direct to WSGI 3.0 will save us some work in drafting any specification at least, I don't see that it will on the basis that at the moment the only difference we are talking about between WSGI 2.0/3.0 is dropping of start_response(). This is because bits of the other stuff already talked about in relation to what we were calling WSGI 2.0 previously, is already a part of what we are now saying is WSGI 1.1/2.0. In other words, the only important thing that has got deferred to WSGI 3.0 is dropping of start_response(). Some of the other comments seem to indicate that perhaps some have much more drastic changes in mind than just that. If you do, then perhaps you want to outline what those other changes may be so can gauge how significant they are. Even if people decide to only go as far as WSGI 2.0 at this point, I would still likely implement WSGI 3.0 as an experimental feature just so people can play with it directly rather than have to fiddle with adapters. It wouldn't be the default version anyway, so its present isn't going to affect the general population. BTW, Python 2.6 can itself be seen as a transitional version in some ways between Python 2.5 and Python 3.0. So, not like the idea of WSGI 2.0 being a transitional version is unique. :-) 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/archive%40mail-archive.com