[Web-SIG] Getting back to WSGI grass roots.

[Etienne Robillard]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

René Dudfield wrote:
> On Wed, Sep 23, 2009 at 1:03 PM, Aaron Watters <arw1961 at yahoo.com> wrote:
>>
>> --- On Wed, 9/23/09, Graham Dumpleton <graham.dumpleton at gmail.com> wrote:
>>
>>
>>> So, rather than throw away completely the idea of bytes
>>> everywhere,
>>> and rewrite the WSGI specification, we could instead say
>>> that the
>>> existing conceptual idea of WSGI 1.0 is still valid, and
>>> just build on
>>> top of it a translation interface to present that as
>>> unicode.
>> Seconded.  There should be a lower level that talks bytes
>> and a higher level that talks unicode or whatever.
>> There should also be a way for
>> even higher levels to reach down
>> to the lower level to see the bytes before they got
>> misdecoded by the unicode layer because this will
>> likely be needed in some cases.  Is there anything
>> wrong with just adding decoded interpretations to
>> the WSGI environment as separate entries?
>>
>> Also, everything should be as orthogonal as possible.
>> One problem I have with most Web tools and frameworks
>> is they tend to take over and do everything at once
>> when I really only want a little bit of help.  WSGI 1
>> is nice because it just abstracts HTTP and stops there.
>> It was a beautiful piece of work.  Kudos.
>>
> 
> Yeah, wsgi is definitely useful for a wide range of uses cases.
> 
> Except it's currently not working for a number of use cases... but we
> can't accommodate them.  eg, unicode, tainting, http proxies, http
> clients, user supplied buffers, async, latest http RFCs, different
> uses of http compared to 2003, all features of http.  This is clear by
> the variety of web frameworks that don't use wsgi, and the variety of
> things layered on top of wsgi.
> 
> There's room for other specifications which consider those use cases
> not covered by wsgi. http proxies cover the main wsgi use case of
> being able to use applications on many servers(apache, nginx lighttpd
> etc) .  Things like webob, and cherrypy allow python frameworks to
> coordinate at a higher level avoiding wsgi as well.
> 
> It's also clear that async frameworks can be used with wsgi in a non
> blocking manner given things like the greenlets/stackless and the
> Eventlet library - which makes use of two underlying async
> frameworks(twisted, and libevent) given that all of your blocking
> calls to libraries can be swapped out with versions written for
> async... like many have already(eg you can use a urllib api like
> library).
> 
> We have to keep remembering what the purpose of wsgi is.  Opening line
> of wsgi spec: "This document specifies a proposed standard interface
> between web servers and Python web applications or frameworks, to
> promote web application portability across a variety of web servers."
> By limiting its scope we do get something useful out of it(for some
> people).
> 
> Application portability is the main wsgi use case.  I think that
> requires a number of things that wsgi doesn't provide - wsgi knows
> nothing of data stores for example.  Application portability is the
> main thing we should be interested in, and strive for it.  Not just on
> web servers, but on web frameworks too.
> 
> There's no way I can take any python web application, copy the files
> onto any python web server and have it work.  php can do this, but we
> still can not do this with python.

Well, I kinda disagree. You can easily distribute eggs or whatever
Python packages to your favorite HTTP web server and have them working
in your current WSGI stack. At least, I don't seem to get how PHP makes
this more easily than with Python. Perhaps putting some lights here
would be helpful.

Please let web frameworks be web frameworks and peps be peps! That is,
allow some flexibility for web frameworks designs by writting clear
and concise peps, but also forget about fairy features that would
increase the document size over 1MB... ;-)

Regards,

Etienne

> _______________________________________________
> Web-SIG mailing list
> Web-SIG at python.org
> Web SIG: http://www.python.org/sigs/web-sig
> Unsubscribe: http://mail.python.org/mailman/options/web-sig/robillard.etienne%40gmail.com
> 


- --
Etienne Robillard <robillard.etienne at gmail.com>
Green Tea Hackers Club <http://gthc.org/>
Blog: <http://gthc.org/blog/>
PGP Fingerprint: 178A BF04 23F0 2BF5 535D  4A57 FD53 FD31 98DC 4E57
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkq6IZQACgkQ/VP9MZjcTldOcQCgyEsupfDxrSIpwVBK85iCuOCZ
cwQAnRWov+VTQqT2T/4gw84hqnjkL7dG
=moxq
-----END PGP SIGNATURE-----