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

[Massimo Di Pierro]

Hi Graham,

Me being an outsider who contributed nothing to the process, I hope  
you'll reconsider.
I really appreciate your work and I trusted the process more with you  
in it.


Massimo

On Sep 23, 2009, at 9:11 PM, P.J. Eby wrote:


At 11:47 AM 9/24/2009 +1000, Graham Dumpleton wrote:
After almost two years of trying to get WSGI for Python 3.0 to fly,  
I really

do think it is time for me to give up. I did say a while back I would
try one last push and this has been it.


___
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

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

[Randy Syring]

P.J. Eby wrote:



I, for one, *really* appreciate the work you put into all of this, as 
I previously commented on your blog post.  And I really hope you'll 
hang in there.  Thanks for all your hard work.



+...15 or so :)

My "+"s may not count for much, but they go to many others as well.  I 
have been amazed at some of the detail and thoughtfulness you are all 
putting into this discussion.  Thank you all for your hard work.


--
Randy Syring
Intelicom
502-644-4776

"Whether, then, you eat or drink or 
whatever you do, do all to the glory

of God." 1 Cor 10:31


___
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

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

[P.J. Eby]

At 11:47 AM 9/24/2009 +1000, Graham Dumpleton wrote:

After almost two years of trying to get WSGI for Python 3.0 to fly, I really
do think it is time for me to give up. I did say a while back I would
try one last push and this has been it.


I'm sorry you feel that way, and I'm sorry if I contributed to any 
frustration on your part.  It wasn't my intention, and I'm really 
taken by surprise, because before Ian's proposal, it sounded like you 
and I were converging towards something very much like what he ended 
up proposing.  Anyway, just...  sorry.


I, for one, *really* appreciate the work you put into all of this, as 
I previously commented on your blog post.  And I really hope you'll 
hang in there.  Thanks for all your hard work.


--PJ

___
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

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

[Graham Dumpleton]

2009/9/24 P.J. Eby :
>> Anyway, that is the thought. Should we be looking at WSGI as a set of
>> layers instead of assuming we have to push unicode into the gateway
>> interface layer?
>
> These are not mutually exclusive options.  However, the set of layers thing,
> if I'm understanding it correctly, is a big fat -1000 -- totally invalidates
> the whole point of WSGI.  Honestly, I don't even like having two versions of
> the spec, which is why the idea of having a "3.0" really ticks me off.
>  Standards don't benefit from having multiple versions, even in disguised
> forms like "layers" or "options".

This isn't really about multiple versions of the specification which
shows you do perhaps simply don't understand. With such a negative
response, seems no point in trying to explain to you though.

>> FWIW, I thought of this because I was going to suggest at this point
>> that overall we have a break from the discussion at this point.
>
> I'm not sure I follow you.  Ian has put forth a proposal that I heartily
> support, with the possible exception of a part that I've asked for
> clarification on.  Others have expressed support for that proposal as well,
> and I haven't seen any -1's on it yet.
>
> Perhaps you should take a look at it?  (It's under the "Proposal to remove
> SCRIPT_NAME/PATH_INFO" thread, but it's really a complete proposal for
> moving forward with a single new 2.0 spec.)

I have read it. Right now there is a mere 10 posts in that discussion
which is nothing compared to the scrutiny that other proposals have
got. Other proposals have also had Armin and Robert trying out actual
code to either implement them or investigate the practicality of them
actually working. I have seen no suggestion that this has been done in
regard to Ian's proposal, so it is theoretical only whether other
options have at least been tried to an extent.

Putting aside the technical merits or otherwise of Ian's suggestions,
it falls at a time akin to how governments will introduce new
legislation very late in a sitting (ie., 3am) in the morning, when
most have lost interest or don't care any more. The governments do
this because they know it will not get the scrutiny it should. Now, I
am not saying that Ian has done that deliberately, just that it has
been unfortunate timing in that some of the participants in the
discussions seemed to have faded away and at this point most are
possibly just seeing this as all part of the original discussion
instead of something new and so either not commenting or simply cant
be bothered commenting.

With that in mind, part of what I suggested was for us all to take a
breather and try and get together some concise documentation on a web
site somewhere, along with working code examples for all the different
options, that can sit on top of existing WSGI implementations so that
people can actually try out and experiment with the options and see
what in practice works. This way people can see exactly what is being
suggested rather than having to wade through huge amounts of emails to
distil what is important and what isn't. Don't know why you didn't
understand what I was suggesting in that part of my email.

Anyway, I am at the point that if someone else wants to do that, ie.,
document the proposals and provide example implementation code that
will run on top of WSGI 1.0, they can, but frankly I am not sure I can
be bothered now even though I suggested it.

Overall, I believe I have more or less worked out what I will probably
now do in regard to mod_wsgi and its future, and that decision will
mean I no longer have to care about what you all decide as I wouldn't
necessarily have to implement it anyway. I'll be talking to a few
others off list about if first and then make my final decision. After
almost two years of trying to get WSGI for Python 3.0 to fly, I really
do think it is time for me to give up. I did say a while back I would
try one last push and this has been it.

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

Re: [Web-SIG] Proposal to remove SCRIPT_NAME/PATH_INFO

[Ian Bicking]

On Wed, Sep 23, 2009 at 2:38 PM, P.J. Eby  wrote:

> At 08:42 AM 9/23/2009 +0200, Armin Ronacher wrote:
>
>> > I then propose that we eliminate SCRIPT_NAME and PATH_INFO.  Instead we
>> > have:
>> IMO they should stick around for compatibility with older applications
>> and be latin1 encoded on Python 3.  But the use is discouraged.
>>
>
> One or the other should be there, not both.  If you allow older code to
> work, this means it could change the old ones but not the new, leaving a
> confused mess for child applications to sort out.


This is my strongly-held opinion as well.  It's been a struggle to get
people to provide accurate SCRIPT_NAMEs, and to represent the idea of
SCRIPT_NAME through SCRIPT_NAME (as opposed to a hodge-podge of different
patterns, configuration, etc).  To provide this information twice would be a
big step backwards, allowing for all sorts of weird bugs and inconsistent
behavior when the two weren't in sync, and depending on which key is given
preference in code.

I *wish* SCRIPT_NAME and PATH_INFO had been strictly required in WSGI 1
(they are in CGI, but not WSGI).  If they were, we'd see more of
environ['PATH_INFO'], which would break fast and obviously, and less
environ.get('PATH_INFO', '').  But... too late for that now.  The new key
should definitely be required.  Then code can even do:

if 'wsgi.path_info' in environ:
path_info = urllib.unquote(environ['wsgi.path_info']
else:
path_info = environ.get('PATH_INFO', '')

We should also make sure the new validator works on both versions of WSGI,
which will make it easier to backport checks like making sure wsgi.path_info
is *not* in a WSGI 1 environ.


Not directly in response to this email, several people expressed concern
that some environments provide only the unquoted path.  I think it's not
terribly horrible if they fake it by re-quoting the path.  In CGI/Python 3
this would be something like:

environ['wsgi.script_name'] =
urllib.request.quote(os.environ['SCRIPT_NAME'].encode(sys.getdefaultencoding(),
'surrogateescape'))

(obviously urllib.request.quote needs to be fixed to work on bytes; though
the implementation is also small enough we could show the correct
implementation in the spec, and warn implementors not to trust
urllib.request.quote to work in Python 3.0-3.1.1)

I also believe you can safely reconstruct the real SCRIPT_NAME/PATH_INFO
from REQUEST_URI, which is usually available (at least in contexts where
this sort of thing is a problem).  I am not up to thinking it through right
now, as it's not a trivial algorithm, but I'm sure it can be done.  Really
it's just a question of how much you can avoid brute force, because you
could always do:

def real_path(request_uri, script_name, path_info):
for i in range(request_uri):
if urllib.request.unquote(request_uri[:i]) == script_name:
return request_uri[:i], request_uri[i:]
# Something is messed up, fake it
return urllib.request.quote(script_name),
urllib.request.quote(path_info)

I think you could do better than character-by-character (instead by path
segment), and in particular do it faster when %2f doesn't appear in the path
at all (the common case).  This would be appropriate code for wsgiref.


>
>  If we go about dropping start_response, can we move the app iter to the
>> beginning?  That would be consistent with the signature of common
>> response objects, making it possible to do this:
>>
>>response = Response(*hello_world(environ))
>>
>
> When you say "beginning", do you mean the beginning of the return tuple?
>  That is:
>
>return ['body here'], '200 OK', [('Header', 'value')]
>
> I'd be surprised if a lot of response objects had such a signature, since
> that's not the order a server would actually output that data in.


It'd be more reasonable to change the Response __init__ signature, like:

class Response(object):
def __init__(self, body_or_wsgi_response, status=None, headers=None):
if isinstance(body_or_wsgi_response, tuple):
status, headers, body = body_or_wsgi_response
else:
body = body_or_wsgi_response

If you allow an iterator for a body argument, it could be a tuple; but at
least WebOb doesn't allow iterators, only str/unicode.  (You can give an
iterator, but you need to do it with an app_iter keyword argument.)  I don't
know what Werkzeug or other frameworks allow.


>
>  In general I think doing too many changes at once is harmful
>>
>
> Actually, the reverse is true for standards.  Incremental change means more
> versions, which goes counter to the point of having a standard in the first
> place.


Yeah; WSGI 1.1 is just errata, I expect to change very little code.  I'd
rather make just one change to WSGI 2.  And it doesn't seem so hard really.


-- 
Ian Bicking  |  http://blog.ianbicking.org  |
http://topplabs.org/civichacker
___
Web-SIG mailing list
Web-SIG@python.org
Web SIG: http://www.python.org/sigs/web-sig

Re: [Web-SIG] Proposal to remove SCRIPT_NAME/PATH_INFO

[P.J. Eby]

At 08:42 AM 9/23/2009 +0200, Armin Ronacher wrote:

> I then propose that we eliminate SCRIPT_NAME and PATH_INFO.  Instead we
> have:
IMO they should stick around for compatibility with older applications
and be latin1 encoded on Python 3.  But the use is discouraged.


One or the other should be there, not both.  If you allow older code 
to work, this means it could change the old ones but not the new, 
leaving a confused mess for child applications to sort out.




If we go about dropping start_response, can we move the app iter to the
beginning?  That would be consistent with the signature of common
response objects, making it possible to do this:

response = Response(*hello_world(environ))


When you say "beginning", do you mean the beginning of the return 
tuple?  That is:


return ['body here'], '200 OK', [('Header', 'value')]

I'd be surprised if a lot of response objects had such a signature, 
since that's not the order a server would actually output that data in.




In general I think doing too many changes at once is harmful


Actually, the reverse is true for standards.  Incremental change 
means more versions, which goes counter to the point of having a 
standard in the first place.




The WSGI PEP should standardize a way for the application to figure out
the environment it runs in.  And that I think that should *not* be
checking sys.version_info but rather comparing string features.


The presence of str.decode() should suffice.  If you can decode a 
string, you're on a Python that has bytes-equivalent strings.


___
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

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

[P.J. Eby]

At 02:43 PM 9/23/2009 +1000, Graham Dumpleton wrote:

Sorry, after having had a bit of think while eating lunch, I am going
to throw up another point of view on this whole issue. So, sit back
and be just a little bit concerned.

WSGI stands for Web Server GATEWAY Interface.

My understanding is that right back at the beginning WSGI was purely
intended to only be used at the direct interface with the underlying
web server. This is why I understand, in part at least, the term
'gateway is used in the acronym.


This is incorrect.  WSGI's roots are in an interface that was used 
inside of PEAK applications, as a way of connecting components, and 
allowing pieces from different frameworks to be combined in a single 
application, while also being able to run under CGI or FastCGI or a 
dedicated server.  That interface was basically a CGI-like 
environ/stdin/stdout/stderr, represented as function call arguments.


The original terminology in the December 2003 draft used the term 
"container" as a catchall, rather than distinguishing servers from middleware.




The problem was that people discovered one could apply the same
interface for use as middleware. As we all know, that has been used
quite successfully, but has also been equally abused.


People didn't "discover it" - the term first appeared in the second 
draft of the spec, and was part of the idea before I ever wrote the 
first posting to the Web-SIG; I just didn't use that word.




By seeing WSGI as being layers instead, first thing is that web
frameworks such as web2py and CherryPy which merely use WSGI as the
gateway interface would continue to work directly on this layer,
regardless of whether they use Python 2.X or 3.X. Those frameworks are
already going to translate what ever this interface defines into their
own internal interface and effectively relegate WSGI from any higher
levels of the application.

We now get back to the unicode vs bytes argument we have been having.
This argument will not vanish by virtue of doing this, but instead of
pushing the unicode translation down into the gateway interface layer,
we just apply it on top.


I don't understand what you mean by "layers" here.



To avoid conflict, one could as a minimal measure just add an
additional 'wsgi.' variable which indicates whether interface is
'bytes' or 'unicode' and hope middleware validate they have been
plugged in at the correct level.


Dear please God, no.



Anyway, that is the thought. Should we be looking at WSGI as a set of
layers instead of assuming we have to push unicode into the gateway
interface layer?


These are not mutually exclusive options.  However, the set of layers 
thing, if I'm understanding it correctly, is a big fat -1000 -- 
totally invalidates the whole point of WSGI.  Honestly, I don't even 
like having two versions of the spec, which is why the idea of having 
a "3.0" really ticks me off.  Standards don't benefit from having 
multiple versions, even in disguised forms like "layers" or "options".




FWIW, I thought of this because I was going to suggest at this point
that overall we have a break from the discussion at this point.


I'm not sure I follow you.  Ian has put forth a proposal that I 
heartily support, with the possible exception of a part that I've 
asked for clarification on.  Others have expressed support for that 
proposal as well, and I haven't seen any -1's on it yet.


Perhaps you should take a look at it?  (It's under the "Proposal to 
remove SCRIPT_NAME/PATH_INFO" thread, but it's really a complete 
proposal for moving forward with a single new 2.0 spec.)


___
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

Re: [Web-SIG] Request for Comments on upcoming WSGI Changes

[Philip Jenvey]

On Sep 22, 2009, at 8:28 PM, P.J. Eby wrote:


At 05:12 PM 9/22/2009 -0700, Philip Jenvey wrote:

Because our request container is a plain, pre-fabricated dict that
doesn't permit the lazy behavior.


Not quite true; you can always write a library function,  
get_foo(environ) that does the lazy caching in a private environ  
key, at the cost of also caching the original value and doing a  
consistency check.


Sure, that's what the Werkzeug et al WSGI 1 wrappers are already  
doing, I'm referring to the Python 3 WSGI level itself, assuming it  
returns latin1 decoded native strs. You're talking about a separate  
process on top of WSGI -- this process becomes an unnecessary  
roundtrip compared to the WSGI 1 wrappers, as Armin points out.


--
Philip Jenvey
___
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

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

[Aaron Watters]

--- On Wed, 9/23/09, René Dudfield  wrote:
> 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.

Perhaps there should be a notion of managed application
resources built as another layer on top of WSGI so you
can easily switch between storing things in MySQL or
the file system or Google App Engine data store or
whatever.  Perhaps something along these lines?

http://aaron.oirt.rutgers.edu/myapp/docs/W1000_1000.resources

> 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.

I can :).  This doesn't require changes to WSGI, however,
just appropriate additional layers on top of WSGI which you
can call WSGI++ or give another name -- I don't know which
is better -- ask a marketing person.

  -- Aaron Watters
  http://aaron.oirt.rutgers.edu/myapp/docs/W1100_1400.calc
===

Little birds are playing
Bagpipes on the shore
Where the tourists snore
  "Thanks!" they say,
  "'Tis thrilling!"
  "Take, oh take this shilling!"
  "Let us have no more!"
  -- Lewis Carroll

___
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

Re: [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  wrote:
>>
>> --- On Wed, 9/23/09, Graham Dumpleton  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@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 
Green Tea Hackers Club 
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-
___
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

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

[René Dudfield]

On Wed, Sep 23, 2009 at 1:03 PM, Aaron Watters  wrote:
>
>
> --- On Wed, 9/23/09, Graham Dumpleton  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.
___
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

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

[Aaron Watters]

--- On Wed, 9/23/09, Graham Dumpleton  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.

-- Aaron Watters
http://aaron.oirt.rutgers.edu/myapp/docs/W1100_1600.openFlashCharts

==
All problems in computer science can be solved by 
another level of indirection -- David Wheeler
  [of course the Java folk have proven over and over
   again that you can have too many layers...]

___
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

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

[And Clover]

Graham 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.


I don't think we really need to. Almost nothing in WSGI itself actually 
touches Unicode. HTTP headers may in theory be ISO-8859-1 (and certainly 
should be handled as such), but in the real world they are exclusively 
ASCII (anything else breaks browsers).


SCRIPT_NAME/PATH_INFO is the only part of the spec that potentially 
needs more than ASCII, and even then the majority of apps don't put any 
Unicode characters in those (especially SCRIPT_NAME). I don't think it's 
worth adding the complication of a two-layer interface just for this one 
case.


If we can hack around SCRIPT_NAME/PATH_INFO separately as per the other 
thread there's no longer any need for anything but ASCII, so WSGI's 
strings can be bytes or unicode depending on your taste/Python-version, 
without it hurting anyone. The important job of mapping


* query parameters,
* POSTed request bodies, and
* response bodies

between bytes and unicode remains firmly in the application/framework's 
area of concern and needs no assistance from WSGI.


--
And Clover
mailto:a...@doxdesk.com
http://www.doxdesk.com/
___
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

Re: [Web-SIG] Proposal to remove SCRIPT_NAME/PATH_INFO

[And Clover]

Ian Bicking wrote:


I propose we switch primarily to "native" strings: str on both Python 2 and
3.


Fine.


wsgi.input remains byte-oriented, as does the response app_iter.


Good.


These both form the original path.  It is not URL decoded, so it should be
ASCII.


Great! BUT.

Undecoded script_name/path_info *cannot* be provided by some gateways: 
primarily, but not only, CGI.


Such a gateway can reconstruct what it thinks the undecoded versions 
should have been, but this is not reliably accurate. I would like a way 
(eg. a flag) for the gateway or server to specify to the application 
that script_name/path_info are potentially inaccurate. Then the 
application can react by avoiding IRI (and %2F, though arguably that 
should be avoided anyway).



This sends different text, but is highly preferable.


Yes. All schemes to send non-ASCII in cookies require sending different 
text; URL-encoding is a common choice of ad-hoc wrapping. I don't think 
WSGI has to worry too much about explaining this, it's a known hazard of 
the web in general. It doesn't work in any other environment, so nobody 
should be expecting it to work in WSGI.



What happens if you give unicode text in the response headers that cannot be
encoded as Latin1?


UnicodeEncodeError.


Should some things be unicode on Python 2?


Don't think so.

--
And Clover
mailto:a...@doxdesk.com
http://www.doxdesk.com/


--
And Clover
mailto:a...@doxdesk.com
http://www.doxdesk.com/

___
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

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

[Jim Fulton]

On Wed, Sep 23, 2009 at 12:43 AM, Graham Dumpleton
 wrote:
...
> Anyway, that is the thought. Should we be looking at WSGI as a set of
> layers instead of assuming we have to push unicode into the gateway
> interface layer?

+1

Jim

-- 
Jim Fulton
___
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

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

[Armin Ronacher]

Hi,

Graham Dumpleton schrieb:
> 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.
I could live with that as well.


Regards,
Armin
___
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