From dsp at dsp.name  Sun Apr  2 23:58:13 2006
From: dsp at dsp.name (Doug Porter)
Date: Sun, 02 Apr 2006 17:58:13 -0400
Subject: [Web-SIG] minor bug in PEP 333 example
Message-ID: <20060402215813.814091E3A8B@dorado.c-60.org>

There is a minor bug in the middleware example in PEP 333.


--- pep-0333.txt.orig   Sun Apr  2 17:52:46 2006
+++ pep-0333.txt        Sun Apr  2 17:53:02 2006
@@ -352,7 +352,7 @@
         def __init__(self, application):
             self.application = application
 
-        def __call__(environ, start_response):
+        def __call__(self, environ, start_response):
             
             transform_ok = []
             


-- 
Doug Porter <dsp at dsp.name>

From guido at python.org  Mon Apr  3 21:06:59 2006
From: guido at python.org (Guido van Rossum)
Date: Mon, 3 Apr 2006 12:06:59 -0700
Subject: [Web-SIG] minor bug in PEP 333 example
In-Reply-To: <20060402215813.814091E3A8B@dorado.c-60.org>
References: <20060402215813.814091E3A8B@dorado.c-60.org>
Message-ID: <ca471dc20604031206m223435b2gb13d902d0050e26c@mail.gmail.com>

Thanks, fixed.

On 4/2/06, Doug Porter <dsp at dsp.name> wrote:
> There is a minor bug in the middleware example in PEP 333.
>
>
> --- pep-0333.txt.orig   Sun Apr  2 17:52:46 2006
> +++ pep-0333.txt        Sun Apr  2 17:53:02 2006
> @@ -352,7 +352,7 @@
>          def __init__(self, application):
>              self.application = application
>
> -        def __call__(environ, start_response):
> +        def __call__(self, environ, start_response):
>
>              transform_ok = []
>
>
>
> --
> Doug Porter <dsp at dsp.name>
> _______________________________________________
> 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/guido%40python.org
>


--
--Guido van Rossum (home page: http://www.python.org/~guido/)

From ianb at colorstudy.com  Wed Apr  5 00:26:28 2006
From: ianb at colorstudy.com (Ian Bicking)
Date: Tue, 04 Apr 2006 17:26:28 -0500
Subject: [Web-SIG] html-gen-ish libraries; what's best?
Message-ID: <4432F294.4050605@colorstudy.com>

Are there any opinions on the best HTML/XML generation libraries out there?

For example, HTMLGen being the original (but too eclectic).  Stan is 
often also sited (http://divmod.org/projects/nevow#stan).  I have an 
extension of ElementTree along these lines in FormEncode 
(http://svn.formencode.org/FormEncode/trunk/formencode/htmlgen.py).  I 
noticed http://markup.sourceforge.net/ today, which allows you to open a 
tag and close it later, which can be nice.

I'd like to put a Best Possible library in WebHelpers 
(http://pylonshq.com/WebHelpers/), that's both simple and easy to work 
with.  I would be nice if the same API could be used to generate both 
ElementTree nodes and strings; ElementTree itself can be a little picky, 
so *only* using ElementTree as the internal/intermediate representation 
(like formencode.htmlgen does) might be going too far.  HTML/XHTML 
validation might be interesting.  Smart indentation would be nice, at 
least optionally (i.e., indentation, but nothing that breaks the layout).

While the library would ideally have some (optional) knowledge of HTML, 
it would be out of scope to have it be a general page-builder (like 
HTMLGen, and a bit like markup.sf.net).  I'm more interested in just 
using it to build fragments.

Opinions?

-- 
Ian Bicking  /  ianb at colorstudy.com  /  http://blog.ianbicking.org

From exogen at gmail.com  Wed Apr  5 00:38:47 2006
From: exogen at gmail.com (Brian Beck)
Date: Tue, 04 Apr 2006 18:38:47 -0400
Subject: [Web-SIG] html-gen-ish libraries; what's best?
References: <4432F294.4050605@colorstudy.com>
Message-ID: <e0ushl$k5b$1@sea.gmane.org>

Ian Bicking wrote:
> While the library would ideally have some (optional) knowledge of HTML,
> it would be out of scope to have it be a general page-builder (like
> HTMLGen, and a bit like markup.sf.net).  I'm more interested in just
> using it to build fragments.

Never used it, but I came across XIST and it seems to include a pretty
'complete' way of doing that:
http://www.livinglogic.de/Python/xist/Examples.html

--
Brian Beck
Adventurer of the First Order


From smulloni at smullyan.org  Wed Apr  5 05:40:35 2006
From: smulloni at smullyan.org (Jacob Smullyan)
Date: Tue, 4 Apr 2006 23:40:35 -0400
Subject: [Web-SIG] html-gen-ish libraries; what's best?
In-Reply-To: <4432F294.4050605@colorstudy.com>
References: <4432F294.4050605@colorstudy.com>
Message-ID: <20060405034035.GA11019@smullyan.org>

On Tue, Apr 04, 2006 at 05:26:28PM -0500, Ian Bicking wrote:
> Opinions?

I have an opinion about a related matter, namely, a convenience syntax
for generating nodes.  

One thing I like a lot about stan is its general thrust towards having
a concise, usable, sexp-ish syntax for this task that permits one to
view the document you are creating within Python almost as if it were
markup itself.  However, stan quite deliberately tortures Python
syntax with zany overloading, and while that can be enjoyed for its
own sake (I'd hardly want to discourage zaniness in general, we need
more of it), I don't consider it optimal.  For my work I sometimes use
a very simple module with which I can generate fragments like so:

   node=N('html', 
          A(xmlns='http://www.w3.org/1999/xhtml'),
          ('head',
           N('link', rel='stylesheet', href="styles.css"),
           ('title', 'This is a title')),
          ('body',
           ('p', A('class', 'major'), sometext)))
          
N is short for Node, A for Attribute; tuples are coerced to nodes, and
constructors are flexible so that attributes can be specified either
as keyword arguments, where convenient, or positionally (via the
Attribute class). 
          
My little implementation is a quick hack using elementtree's
SimpleXMLWriter as a back end; if anyone wants it I can post it, but
it is feature-poor and pretty obvious.  My plea is not for it, but
that any such hypothetical Beast of Breed should expose an sexp-ish
way to create documents and fragments (it needn't be the only way),
for which the syntax above might be a conversation starter, and that
such a syntax should behave like Python, and not override access
syntax to do mutation, etc., so that mixing the syntax with Python
will be natural, legible, and free from cognitive dissonance.

Cheers,

js

-- 
Jacob Smullyan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://mail.python.org/pipermail/web-sig/attachments/20060404/a2a43382/attachment.pgp 

From luke.arno at gmail.com  Fri Apr  7 04:10:42 2006
From: luke.arno at gmail.com (Luke Arno)
Date: Thu, 6 Apr 2006 22:10:42 -0400
Subject: [Web-SIG] html-gen-ish libraries; what's best?
In-Reply-To: <4432F294.4050605@colorstudy.com>
References: <4432F294.4050605@colorstudy.com>
Message-ID: <d79e89ce0604061910o7a462b84lfb971362106178f3@mail.gmail.com>

I wrote a little utility called 'pyfo' for just this purpose.

It works for generating any XML you like.

http://foss.cpcc.edu/pyfo/

this:
-------------------------------
markup = ('div',
                  [('h1', 'Example', {'class': 'heading'}),
                   ('p', 'No one expects The Spanish Inquisition!')])

print pyfo(markup, pretty=True)
-------------------------------

outputs:
-------------------------------
<div>
    <h1 class="heading">Example</h1>
    <p>No one expects The Spanish Inquisition!</p>
</div>
-------------------------------

This has turned out to be extremely convenient for me.
YMMV.

Cheers,
- Luke

http://lukearno.com/

On 4/4/06, Ian Bicking <ianb at colorstudy.com> wrote:
> Are there any opinions on the best HTML/XML generation libraries out there?
>
> For example, HTMLGen being the original (but too eclectic).  Stan is
> often also sited (http://divmod.org/projects/nevow#stan).  I have an
> extension of ElementTree along these lines in FormEncode
> (http://svn.formencode.org/FormEncode/trunk/formencode/htmlgen.py).  I
> noticed http://markup.sourceforge.net/ today, which allows you to open a
> tag and close it later, which can be nice.
>
> I'd like to put a Best Possible library in WebHelpers
> (http://pylonshq.com/WebHelpers/), that's both simple and easy to work
> with.  I would be nice if the same API could be used to generate both
> ElementTree nodes and strings; ElementTree itself can be a little picky,
> so *only* using ElementTree as the internal/intermediate representation
> (like formencode.htmlgen does) might be going too far.  HTML/XHTML
> validation might be interesting.  Smart indentation would be nice, at
> least optionally (i.e., indentation, but nothing that breaks the layout).
>
> While the library would ideally have some (optional) knowledge of HTML,
> it would be out of scope to have it be a general page-builder (like
> HTMLGen, and a bit like markup.sf.net).  I'm more interested in just
> using it to build fragments.
>
> Opinions?
>
> --
> Ian Bicking  /  ianb at colorstudy.com  /  http://blog.ianbicking.org
> _______________________________________________
> 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/luke.arno%40gmail.com
>

From chad at zetaweb.com  Wed Apr 12 08:04:59 2006
From: chad at zetaweb.com (Chad Whitacre)
Date: Wed, 12 Apr 2006 02:04:59 -0400
Subject: [Web-SIG] [ANN] httpy 0.9a2 -- a sane and robust HTTP server and
 library for Python
Message-ID: <443C988B.5090905@zetaweb.com>

Greetings, program!

I am pleased to announce the second public release of httpy -- a sane 
and robust HTTP server and library for Python. Highlights in this release:

     - Responders may now return a Response object in addition to raising
       one.

     - Response headers may now be specified as a list of 2-tuples or a
       dictionary; either are converted to an email.Message.Message
       object by the constructor.

     - The module hierarchy is now more deeply nested to avoid importing
       unused modules.

     - httpy now logs access to stdout in the Combined Log Format, and
       errors to stderr.


Downloads and full documentation are available at:

   http://www.zetadev.com/software/httpy/




chad


From ianb at colorstudy.com  Mon Apr 17 17:39:59 2006
From: ianb at colorstudy.com (Ian Bicking)
Date: Mon, 17 Apr 2006 10:39:59 -0500
Subject: [Web-SIG] [Fwd: Summer of Code preparation]
Message-ID: <4443B6CF.1080500@colorstudy.com>

Hi guys... looks like Google SoC is back on again.  I'm hoping we get 
some good web stuff going on, so people should start thinking.  Also 
there's two wiki pages where you can add project ideas: 
http://wiki.python.org/moin/SummerOfCode and the somewhat out-of-date 
(and needs cleaning) page from last year: 
http://wiki.python.org/moin/CodingProjectIdeas



-------- Original Message --------
Subject: [Python-3000] Summer of Code preparation
Date: Mon, 17 Apr 2006 00:43:33 -0700
From: Neal Norwitz <nnorwitz at gmail.com>

We've only got a short time to get setup for Google's Summer of Code.
We need to start identifying mentors and collecting ideas for students
to implement.  We have the SimpleTodo list
(http://wiki.python.org/moin/SimpleTodo), but nothing on the SoC page
yet (http://wiki.python.org/moin/SummerOfCode).

I can help manage the process from inside Google, but I need help
gathering mentors and ideas.  I'm not certain of the process, but if
you are interested in being a mentor, send me an email.  I will try to
find all the necessary info and post here again tomorrow.  Pass the
word!  I hope all mentors from last year will return again this year.

Can someone take ownership of drumming up mentors and ideas?  We also
need to spread the word to c.l.p and beyond.

Thanks,
n

From titus at caltech.edu  Mon Apr 17 18:30:00 2006
From: titus at caltech.edu (Titus Brown)
Date: Mon, 17 Apr 2006 09:30:00 -0700
Subject: [Web-SIG] [Fwd: Summer of Code preparation]
In-Reply-To: <4443B6CF.1080500@colorstudy.com>
References: <4443B6CF.1080500@colorstudy.com>
Message-ID: <20060417163000.GB20584@caltech.edu>

On Mon, Apr 17, 2006 at 10:39:59AM -0500, Ian Bicking wrote:
-> Hi guys... looks like Google SoC is back on again.  I'm hoping we get 
-> some good web stuff going on, so people should start thinking.  Also 
-> there's two wiki pages where you can add project ideas: 
-> http://wiki.python.org/moin/SummerOfCode and the somewhat out-of-date 
-> (and needs cleaning) page from last year: 
-> http://wiki.python.org/moin/CodingProjectIdeas

I'm thinking of proposing a project to build a JavaScript interpreter
interface for Python; the goal (for me) is to get twill/mechanize to
understand JavaScript.  I think the project has wider applications,
but I'm not sure what people actually want to do with JavaScript.
I could imagine server-side parsing of javascript, and/or integration of 
javascript and python code.  Thoughts?

--titus

From ianb at colorstudy.com  Mon Apr 17 18:47:12 2006
From: ianb at colorstudy.com (Ian Bicking)
Date: Mon, 17 Apr 2006 11:47:12 -0500
Subject: [Web-SIG] [Fwd: Summer of Code preparation]
In-Reply-To: <20060417163000.GB20584@caltech.edu>
References: <4443B6CF.1080500@colorstudy.com>
	<20060417163000.GB20584@caltech.edu>
Message-ID: <4443C690.2050401@colorstudy.com>

Titus Brown wrote:
> On Mon, Apr 17, 2006 at 10:39:59AM -0500, Ian Bicking wrote:
> -> Hi guys... looks like Google SoC is back on again.  I'm hoping we get 
> -> some good web stuff going on, so people should start thinking.  Also 
> -> there's two wiki pages where you can add project ideas: 
> -> http://wiki.python.org/moin/SummerOfCode and the somewhat out-of-date 
> -> (and needs cleaning) page from last year: 
> -> http://wiki.python.org/moin/CodingProjectIdeas
> 
> I'm thinking of proposing a project to build a JavaScript interpreter
> interface for Python; the goal (for me) is to get twill/mechanize to
> understand JavaScript.  I think the project has wider applications,
> but I'm not sure what people actually want to do with JavaScript.
> I could imagine server-side parsing of javascript, and/or integration of 
> javascript and python code.  Thoughts?

Do you mean like integrating Mozilla's Spidermonkey with Python?  That 
would be a very approachable and useful project, I think.  It even gets 
us a restricted execution environment ;)

I'm personally non-plussed by deeper integration, like parsing 
Javascript in Python or otherwise mingling the runtimes.  But I know 
other people find the idea of that sort of thing much more appealing 
than I do.  Regardless of motivation, I think the simpler Spidermonkey 
integration would be more useful *and* much easier.  Definitely an 
interesting idea -- and the more I think about the restricted execution 
aspect, the more plausibly useful that sounds.  (Rich templating 
languages using Javascript?)

I think Brett Cannon is doing something specifically related to Python 
and Javascript for his doctorate, though what exactly that entails is a 
little less clear to me -- I think it's more related to Python in the 
browser, which is kind of the flip side of this.


-- 
Ian Bicking  /  ianb at colorstudy.com  /  http://blog.ianbicking.org

From titus at caltech.edu  Mon Apr 17 19:35:02 2006
From: titus at caltech.edu (Titus Brown)
Date: Mon, 17 Apr 2006 10:35:02 -0700
Subject: [Web-SIG] [Fwd: Summer of Code preparation]
In-Reply-To: <4443C690.2050401@colorstudy.com>
References: <4443B6CF.1080500@colorstudy.com>
	<20060417163000.GB20584@caltech.edu>
	<4443C690.2050401@colorstudy.com>
Message-ID: <20060417173502.GB2035@caltech.edu>

On Mon, Apr 17, 2006 at 11:47:12AM -0500, Ian Bicking wrote:
-> Titus Brown wrote:
-> > On Mon, Apr 17, 2006 at 10:39:59AM -0500, Ian Bicking wrote:
-> > -> Hi guys... looks like Google SoC is back on again.  I'm hoping we get 
-> > -> some good web stuff going on, so people should start thinking.  Also 
-> > -> there's two wiki pages where you can add project ideas: 
-> > -> http://wiki.python.org/moin/SummerOfCode and the somewhat out-of-date 
-> > -> (and needs cleaning) page from last year: 
-> > -> http://wiki.python.org/moin/CodingProjectIdeas
-> > 
-> > I'm thinking of proposing a project to build a JavaScript interpreter
-> > interface for Python; the goal (for me) is to get twill/mechanize to
-> > understand JavaScript.  I think the project has wider applications,
-> > but I'm not sure what people actually want to do with JavaScript.
-> > I could imagine server-side parsing of javascript, and/or integration of 
-> > javascript and python code.  Thoughts?
-> 
-> Do you mean like integrating Mozilla's Spidermonkey with Python?  That 
-> would be a very approachable and useful project, I think.  It even gets 
-> us a restricted execution environment ;)

Yes, something like this.  Personally I'd be happy to get good
twill/mechanize integration, but methinks a complete wrapper that is
then hooked into twill/mechanize is the proper way to go.  Then it
would be of use to others.

-> I'm personally non-plussed by deeper integration, like parsing 
-> Javascript in Python or otherwise mingling the runtimes.  But I know 
-> other people find the idea of that sort of thing much more appealing 
-> than I do.  Regardless of motivation, I think the simpler Spidermonkey 
-> integration would be more useful *and* much easier.  Definitely an 
-> interesting idea -- and the more I think about the restricted execution 
-> aspect, the more plausibly useful that sounds.  (Rich templating 
-> languages using Javascript?)
-> 
-> I think Brett Cannon is doing something specifically related to Python 
-> and Javascript for his doctorate, though what exactly that entails is a 
-> little less clear to me -- I think it's more related to Python in the 
-> browser, which is kind of the flip side of this.

I'll look into it, thanks!

--titus

From janssen at parc.com  Mon Apr 17 20:52:03 2006
From: janssen at parc.com (Bill Janssen)
Date: Mon, 17 Apr 2006 11:52:03 PDT
Subject: [Web-SIG] [Fwd: Summer of Code preparation]
In-Reply-To: Your message of "Mon, 17 Apr 2006 09:47:12 PDT."
	<4443C690.2050401@colorstudy.com> 
Message-ID: <06Apr17.115210pdt."58633"@synergy1.parc.xerox.com>

Ian,

It's getting very hard to do good Web-page-understanding without a
javascript interpreter.  Ideally, this would execute in a Python
context so that each Javascript call (or statement, or expression
evaluation) could invoke Python code to do introspection over the
activity.

As you say, it's the flip side of Python in the browser.

Bill

From ianb at colorstudy.com  Mon Apr 17 21:54:38 2006
From: ianb at colorstudy.com (Ian Bicking)
Date: Mon, 17 Apr 2006 14:54:38 -0500
Subject: [Web-SIG] [Fwd: Summer of Code preparation]
In-Reply-To: <06Apr17.115210pdt."58633"@synergy1.parc.xerox.com>
References: <06Apr17.115210pdt."58633"@synergy1.parc.xerox.com>
Message-ID: <4443F27E.30607@colorstudy.com>

Bill Janssen wrote:
> Ian,
> 
> It's getting very hard to do good Web-page-understanding without a
> javascript interpreter.  Ideally, this would execute in a Python
> context so that each Javascript call (or statement, or expression
> evaluation) could invoke Python code to do introspection over the
> activity.

Do you mean like implementing the DOM in Python, and providing DOM 
objects to Javascript?  Or actually watching the Javascript execute at 
some level?  Providing Python objects seems like a kind of bare minimum 
usefulness, and must already be possible at some level in current 
Javascript implementations.  Actually watching the program runs seems 
harder, and depends on the particulars of the Javascript interpreter 
that you are embedding.  Though I'd guess that already exists to some 
degree as well, because for instance in current interpreters you can 
limit the amount of time the Javascript is given to execute.


-- 
Ian Bicking  /  ianb at colorstudy.com  /  http://blog.ianbicking.org

From janssen at parc.com  Mon Apr 17 22:38:45 2006
From: janssen at parc.com (Bill Janssen)
Date: Mon, 17 Apr 2006 13:38:45 PDT
Subject: [Web-SIG] [Fwd: Summer of Code preparation]
In-Reply-To: Your message of "Mon, 17 Apr 2006 12:54:38 PDT."
	<4443F27E.30607@colorstudy.com> 
Message-ID: <06Apr17.133851pdt."58633"@synergy1.parc.xerox.com>

> > It's getting very hard to do good Web-page-understanding without a
> > javascript interpreter.  Ideally, this would execute in a Python
> > context so that each Javascript call (or statement, or expression
> > evaluation) could invoke Python code to do introspection over the
> > activity.
> 
> Do you mean like implementing the DOM in Python, and providing DOM 
> objects to Javascript?  Or actually watching the Javascript execute at 
> some level?

I meant actually watching the Javascript execute, though of course
providing the DOM as Python objects would be, as you say, a bare
minimum.  One way to this would be to translate the Javascript into
Python, and use existing introspection hooks to watch the Python
execute.

Bill

From pywebsig at alan.kennedy.name  Tue Apr 18 12:04:24 2006
From: pywebsig at alan.kennedy.name (Alan Kennedy)
Date: Tue, 18 Apr 2006 11:04:24 +0100
Subject: [Web-SIG] [Fwd: Summer of Code preparation]
In-Reply-To: <20060417163000.GB20584@caltech.edu>
References: <4443B6CF.1080500@colorstudy.com>
	<20060417163000.GB20584@caltech.edu>
Message-ID: <4a951aa00604180304i1db5939ahda979f272bb4ede8@mail.gmail.com>

[Titus Brown]
> I'm thinking of proposing a project to build a JavaScript interpreter
> interface for Python; the goal (for me) is to get twill/mechanize to
> understand JavaScript.  I think the project has wider applications,
> but I'm not sure what people actually want to do with JavaScript.
> I could imagine server-side parsing of javascript, and/or integration of
> javascript and python code.  Thoughts?

Have you looked at WebCleaner? WebCleaner is a filtering HTTP proxy,
written in python.

http://webcleaner.sourceforge.net/

WebCleaner uses the Mozilla SpiderMonkey javascript engine to execute
JS from web pages: From the webcleaner front page

"""
Another feature is the JavaScript filtering: JavaScript data is
executed in the integrated Spidermonkey JavaScript engine which is
also used by the Mozilla browser suite. This eliminates all JavaScript
obfuscation, popups, and document.write() stuff, but the other
JavaScript functions still work as usual.
"""

Perhaps webcleaner has code that already does what you need? Although
the GPL licensing might be problematic.

Regards,

Alan.

From ianb at colorstudy.com  Tue Apr 18 18:06:02 2006
From: ianb at colorstudy.com (Ian Bicking)
Date: Tue, 18 Apr 2006 11:06:02 -0500
Subject: [Web-SIG] [Fwd: Summer of Code preparation]
In-Reply-To: <4a951aa00604180304i1db5939ahda979f272bb4ede8@mail.gmail.com>
References: <4443B6CF.1080500@colorstudy.com>	<20060417163000.GB20584@caltech.edu>
	<4a951aa00604180304i1db5939ahda979f272bb4ede8@mail.gmail.com>
Message-ID: <44450E6A.6070807@colorstudy.com>

Alan Kennedy wrote:
> [Titus Brown]
> 
>>I'm thinking of proposing a project to build a JavaScript interpreter
>>interface for Python; the goal (for me) is to get twill/mechanize to
>>understand JavaScript.  I think the project has wider applications,
>>but I'm not sure what people actually want to do with JavaScript.
>>I could imagine server-side parsing of javascript, and/or integration of
>>javascript and python code.  Thoughts?
> 
> 
> Have you looked at WebCleaner? WebCleaner is a filtering HTTP proxy,
> written in python.
> 
> http://webcleaner.sourceforge.net/

And the work just disappears... anyway, I downloaded it, and it does 
seem to include a Javascript interpreter.  Couldn't get it to build 
under Python 2.4, but maybe my headers are messed up on this machine or 
something.  Definitely something to look into.

> Perhaps webcleaner has code that already does what you need? Although
> the GPL licensing might be problematic.

Assuming that the bindings were written for webcleaner, the author might 
be willing to change the license just on that part (if the JS bindings 
were also extracted from webcleaner).  Or maybe they came from somewhere 
else originally.

-- 
Ian Bicking  /  ianb at colorstudy.com  /  http://blog.ianbicking.org

From floydophone at gmail.com  Tue Apr 18 18:56:26 2006
From: floydophone at gmail.com (Peter Hunt)
Date: Tue, 18 Apr 2006 12:56:26 -0400
Subject: [Web-SIG] [Fwd: Summer of Code preparation]
Message-ID: <6654eac40604180956g2f5f3a01o36ec3ad809ea8871@mail.gmail.com>

Hi guys,

I think an interesting project would be complete integration of the client
and server via AJAX. That is, whenever a DHTML event handler needs to be
called on the client-side, the document state is serialized and it is sent
along with the DHTML event information to the server, informing it that an
event occured. Then, using something similar to Nevow's LivePage, it could
asynchronously send back JavaScript code to update client state based on
actions on the server. Ideally, on the server-side we'd have a magic
document object which is updated with the document state every request, and
whenever a property is written or a method is called, corresponding
JavaScript is sent via our LivePage mechanism to the client.

Thoughts?

Peter Hunt
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/web-sig/attachments/20060418/e881f57d/attachment.htm 

From jw at perfectproof.com  Wed Apr 19 16:12:48 2006
From: jw at perfectproof.com (John Weissberg)
Date: Wed, 19 Apr 2006 14:12:48 +0000 (UTC)
Subject: [Web-SIG] transaction  progress with cgi.FieldStorage
References: <43AAE16B.9040006@gmail.com>
	<20060111160621.GB61466@prometheusresearch.com>
Message-ID: <loom.20060419T161204-348@post.gmane.org>

We are very interested in this widget. Have you been able to complete it?




From matt at pollenation.net  Wed Apr 19 18:23:39 2006
From: matt at pollenation.net (Matt Goodall)
Date: Wed, 19 Apr 2006 17:23:39 +0100
Subject: [Web-SIG] [Fwd: Summer of Code preparation]
In-Reply-To: <6654eac40604180956g2f5f3a01o36ec3ad809ea8871@mail.gmail.com>
References: <6654eac40604180956g2f5f3a01o36ec3ad809ea8871@mail.gmail.com>
Message-ID: <4446640B.6040004@pollenation.net>

Peter Hunt wrote:
> Hi guys,
> 
> I think an interesting project would be complete integration of the
> client and server via AJAX. That is, whenever a DHTML event handler
> needs to be called on the client-side, the document state is serialized
> and it is sent along with the DHTML event information to the server,
> informing it that an event occured. Then, using something similar to
> Nevow's LivePage, it could asynchronously send back JavaScript code to
> update client state based on actions on the server. Ideally, on the
> server-side we'd have a magic document object which is updated with the
> document state every request, and whenever a property is written or a
> method is called, corresponding JavaScript is sent via our LivePage
> mechanism to the client.
> 
> Thoughts?


Invoking something server-side every time there's some (interesting)
event in the browser will almost certainly perform badly due to network
latency and possibly put unnecessary load on the server.

Serializing and sending document state will only make it slower.

A better approach is probably something like Nevow's Athena widget where
there is a server-side Python object "bound" to a client-side JavaScript
object that manages a fragment of the page.

The Python and JavaScript Athena widgets can send messages when
necessary and at whatever granularity is applicable to the application.

- Matt

-- 
     __
    /  \__     Matt Goodall, Pollenation Internet Ltd
    \__/  \    w: http://www.pollenation.net
  __/  \__/    e: matt at pollenation.net
 /  \__/  \    t: +44 (0)113 2252500
 \__/  \__/
 /  \          Any views expressed are my own and do not necessarily
 \__/          reflect the views of my employer.

From pywebsig at alan.kennedy.name  Wed Apr 19 18:34:29 2006
From: pywebsig at alan.kennedy.name (Alan Kennedy)
Date: Wed, 19 Apr 2006 17:34:29 +0100
Subject: [Web-SIG] [Fwd: Summer of Code preparation]
In-Reply-To: <4446640B.6040004@pollenation.net>
References: <6654eac40604180956g2f5f3a01o36ec3ad809ea8871@mail.gmail.com>
	<4446640B.6040004@pollenation.net>
Message-ID: <4a951aa00604190934w5898edb3u1287e42cd3b93680@mail.gmail.com>

[Peter Hunt]
>> I think an interesting project would be complete integration of the
>> client and server via AJAX. That is, whenever a DHTML event handler
>> needs to be called on the client-side, the document state is serialized
>> and it is sent along with the DHTML event information to the server,
>> informing it that an event occured.

[Matt Goodall]
> Invoking something server-side every time there's some (interesting)
> event in the browser will almost certainly perform badly due to network
> latency and possibly put unnecessary load on the server.

I was going to refrain from this conversation, but now find the
following point relevant:

How long before we end up reinventing X-windows-style transmission of
UI events across the network, i.e. by sending all browser events over
HTTP to the server?

It's worth noting that, in the early days of X-windows, people said it
was far too heavyweight, and would saturate networks and quickly
become unusable. But those people reckoned without advances in network
technology, and the X-windows people claimed that they were
specifically designing for network technologies from several years in
the future, by which time their software technology would be mature
and ready to take advantage of the newer and higher bandwidths. And
they were pretty much right: having used X-windows over corporate WANs
since the early 1990s, I think it works pretty well.

But the X-windows people weren't designing for Internet scale: how
many connections should a server be able to handle?

> Serializing and sending document state will only make it slower.

Agreed: serialising and transmitting whole documents is taking it too far ;-)

Regards,

Alan.

From janssen at parc.com  Wed Apr 19 19:51:39 2006
From: janssen at parc.com (Bill Janssen)
Date: Wed, 19 Apr 2006 10:51:39 PDT
Subject: [Web-SIG] [Fwd: Summer of Code preparation]
In-Reply-To: Your message of "Wed, 19 Apr 2006 09:34:29 PDT."
	<4a951aa00604190934w5898edb3u1287e42cd3b93680@mail.gmail.com> 
Message-ID: <06Apr19.105139pdt."58633"@synergy1.parc.xerox.com>

> But the X-windows people weren't designing for Internet scale: how
> many connections should a server be able to handle?

Well, that's where HTTP-ng came in.  In particular, look at the WebMUX
document, http://www.w3.org/Protocols/MUX/WD-mux-980722.html, which we
implemented for ILU.  I often wish I had it around today for AJAX...

Bill

From guido at python.org  Fri Apr 28 20:03:47 2006
From: guido at python.org (Guido van Rossum)
Date: Fri, 28 Apr 2006 11:03:47 -0700
Subject: [Web-SIG] Adding wsgiref to stdlib
Message-ID: <ca471dc20604281103o3cc9ea5fnd7e03dd724f7b0b0@mail.gmail.com>

PEP 333 specifies WSGI, the Python Web Server Gateway Interface v1.0;
it's written by Phillip Eby who put a lot of effort in it to make it
acceptable to very diverse web frameworks. The PEP has been well
received by web framework makers and users.

As a supplement to the PEP, Phillip has written a reference
implementation, "wsgiref". I don't know how many people have used
wsgiref; I'm using it myself for an intranet webserver and am very
happy with it. (I'm asking Phillip to post the URL for the current
source; searching for it produces multiple repositories.)

I believe that it would be a good idea to add wsgiref to the stdlib,
after some minor cleanups such as removing the extra blank lines that
Phillip puts in his code. Having standard library support will remove
the last reason web framework developers might have to resist adopting
WSGI, and the resulting standardization will help web framework users.

Last time this was brought up there were feature requests and
discussion on how "industrial strength" the webserver in wsgiref ought
to be but nothing like the flamefest that setuptools caused (no
comments please).

I'm inviting people to discuss the addition of wsgiref to the standard
library. I'd like the discussion to be finished before a3 goes out;
technically it can go in up till the b1 code freeze, but I don't
really want to push it that close. I'd like the focus of the
discussion to be "what are the risks of adding wsgiref to the stdlib";
not "what could we think of that's even better". Achieving a perfect
decision is not the goal; having general consensus that adding it
would be better than not adding is would be good. Pointing out
specific bugs in wsgiref and suggesting how they ought to be fixed is
also welcome.

--
--Guido van Rossum (home page: http://www.python.org/~guido/)

From janssen at parc.com  Fri Apr 28 20:31:09 2006
From: janssen at parc.com (Bill Janssen)
Date: Fri, 28 Apr 2006 11:31:09 PDT
Subject: [Web-SIG] [Python-Dev] Adding wsgiref to stdlib
In-Reply-To: Your message of "Fri, 28 Apr 2006 11:03:47 PDT."
	<ca471dc20604281103o3cc9ea5fnd7e03dd724f7b0b0@mail.gmail.com> 
Message-ID: <06Apr28.113116pdt."58641"@synergy1.parc.xerox.com>

> I'm inviting people to discuss the addition of wsgiref to the standard
> library. I'd like the discussion to be finished before a3 goes out;

+1.

I think it's faily low-risk.  WSGI has been discussed and implemented
for well over a year; there are many working implementations of the
spec.  Adding wsgiref to the stdlib would help other implementors of
the spec.

I think there should be a better server implementation in the stdlib,
but I think that can be added separately.  (Personally, I'd like to
find the time to (a) make Medusa thread-safe, and (b) add WSGI to it.
If anyone would like to help with that, send me mail.)

Bill

From pje at telecommunity.com  Fri Apr 28 20:36:11 2006
From: pje at telecommunity.com (Phillip J. Eby)
Date: Fri, 28 Apr 2006 14:36:11 -0400
Subject: [Web-SIG] [Python-Dev] Adding wsgiref to stdlib
In-Reply-To: <ca471dc20604281103o3cc9ea5fnd7e03dd724f7b0b0@mail.gmail.co
 m>
Message-ID: <5.1.1.6.0.20060428142518.01e2b180@mail.telecommunity.com>

At 11:03 AM 4/28/2006 -0700, Guido van Rossum wrote:
>(I'm asking Phillip to post the URL for the current
>source; searching for it produces multiple repositories.)

Source browsing: http://svn.eby-sarna.com/wsgiref/
Anonymous SVN:   svn://svn.eby-sarna.com/svnroot/wsgiref



From ianb at colorstudy.com  Fri Apr 28 21:32:35 2006
From: ianb at colorstudy.com (Ian Bicking)
Date: Fri, 28 Apr 2006 14:32:35 -0500
Subject: [Web-SIG] Adding wsgiref to stdlib
In-Reply-To: <ca471dc20604281103o3cc9ea5fnd7e03dd724f7b0b0@mail.gmail.com>
References: <ca471dc20604281103o3cc9ea5fnd7e03dd724f7b0b0@mail.gmail.com>
Message-ID: <44526DD3.4010807@colorstudy.com>

Guido van Rossum wrote:
> PEP 333 specifies WSGI, the Python Web Server Gateway Interface v1.0;
> it's written by Phillip Eby who put a lot of effort in it to make it
> acceptable to very diverse web frameworks. The PEP has been well
> received by web framework makers and users.
> 
> As a supplement to the PEP, Phillip has written a reference
> implementation, "wsgiref". I don't know how many people have used
> wsgiref; I'm using it myself for an intranet webserver and am very
> happy with it. (I'm asking Phillip to post the URL for the current
> source; searching for it produces multiple repositories.)
> 
> I believe that it would be a good idea to add wsgiref to the stdlib,
> after some minor cleanups such as removing the extra blank lines that
> Phillip puts in his code. Having standard library support will remove
> the last reason web framework developers might have to resist adopting
> WSGI, and the resulting standardization will help web framework users.

I'd like to include paste.lint with that as well (as wsgiref.lint or 
whatever).  Since the last discussion I enumerated in the docstring all 
the checks it does.  There's still some outstanding issues, mostly where 
I'm not sure if it is too restrictive (marked with @@ in the source). 
It's at:

   http://svn.pythonpaste.org/Paste/trunk/paste/lint.py

I think another useful addition would be some prefix-based dispatcher, 
similar to paste.urlmap (but probably a bit simpler): 
http://svn.pythonpaste.org/Paste/trunk/paste/urlmap.py

The motivation there is to give people the basic tools to simple 
multi-application hosting, and in the process implicitly suggest how 
other dispatching can be done.  I think this is something that doesn't 
occur to people naturally, and they see it as a flaw in the server (that 
the server doesn't have a dispatching feature), and the result is either 
frustration, griping, or bad kludges.  By including a basic 
implementation of WSGI-based dispatching the standard library can lead 
people in the right direction for more sophisticated dispatching.

And prefix dispatching is also quite useful on its own, it's not just 
educational.

> Last time this was brought up there were feature requests and
> discussion on how "industrial strength" the webserver in wsgiref ought
> to be but nothing like the flamefest that setuptools caused (no
> comments please).

No one disagreed with the basic premise though, just some questions 
about the particulars of the server.  I think there were at least a 
couple small suggestions for the wsgiref server; in particular maybe a 
slight refactoring to make it easier to use with https.


-- 
Ian Bicking  /  ianb at colorstudy.com  /  http://blog.ianbicking.org

From guido at python.org  Fri Apr 28 21:47:44 2006
From: guido at python.org (Guido van Rossum)
Date: Fri, 28 Apr 2006 12:47:44 -0700
Subject: [Web-SIG] Adding wsgiref to stdlib
In-Reply-To: <44526DD3.4010807@colorstudy.com>
References: <ca471dc20604281103o3cc9ea5fnd7e03dd724f7b0b0@mail.gmail.com>
	<44526DD3.4010807@colorstudy.com>
Message-ID: <ca471dc20604281247k23a586aayd1b7f1c9241e782a@mail.gmail.com>

On 4/28/06, Ian Bicking <ianb at colorstudy.com> wrote:
> I'd like to include paste.lint with that as well (as wsgiref.lint or
> whatever).  Since the last discussion I enumerated in the docstring all
> the checks it does.  There's still some outstanding issues, mostly where
> I'm not sure if it is too restrictive (marked with @@ in the source).
> It's at:
>
>    http://svn.pythonpaste.org/Paste/trunk/paste/lint.py

That looks fine to me; I'm not in this business full-time so I'll
await others' responses.

> I think another useful addition would be some prefix-based dispatcher,
> similar to paste.urlmap (but probably a bit simpler):
> http://svn.pythonpaste.org/Paste/trunk/paste/urlmap.py

IMO this is getting into framework design. Perhaps something like this
could be added in 2.6?

--
--Guido van Rossum (home page: http://www.python.org/~guido/)

From ianb at colorstudy.com  Fri Apr 28 22:03:18 2006
From: ianb at colorstudy.com (Ian Bicking)
Date: Fri, 28 Apr 2006 15:03:18 -0500
Subject: [Web-SIG] Adding wsgiref to stdlib
In-Reply-To: <ca471dc20604281247k23a586aayd1b7f1c9241e782a@mail.gmail.com>
References: <ca471dc20604281103o3cc9ea5fnd7e03dd724f7b0b0@mail.gmail.com>	
	<44526DD3.4010807@colorstudy.com>
	<ca471dc20604281247k23a586aayd1b7f1c9241e782a@mail.gmail.com>
Message-ID: <44527506.2070407@colorstudy.com>

Guido van Rossum wrote:
>> I think another useful addition would be some prefix-based dispatcher,
>> similar to paste.urlmap (but probably a bit simpler):
>> http://svn.pythonpaste.org/Paste/trunk/paste/urlmap.py
> 
> 
> IMO this is getting into framework design. Perhaps something like this
> could be added in 2.6?

I don't think it's frameworky.  It could be used to build a very 
primitive framework, but even then it's not a particularly useful 
starting point.

In Paste this would generally be used below any framework (or above I 
guess, depending on which side is "up").  You'd pass /blog to a blog 
app, /cms to a cms app, etc.  WSGI already is very specific about what 
needs to be done when doing this dispatching (adjusting SCRIPT_NAME and 
PATH_INFO), and that's all that the dispatching needs to do.

The applications themselves are written in some framework with internal 
notions of URL dispatching, but this doesn't infringe upon those. 
(Unless the framework doesn't respect SCRIPT_NAME and PATH_INFO; but 
that's their problem, as the dispatcher is just using what's already 
allowed for in the WSGI spec.)  It also doesn't overlap with frameworks, 
as prefix-based dispatching isn't really that useful in a framework.

The basic implementation is:

class PrefixDispatch(object):
     def __init__(self):
         self.applications = {}
     def add_application(self, prefix, app):
         self.applications[prefix] = app
     def __call__(self, environ, start_response):
         apps = sorted(self.applications.items(),
                       key=lambda x: -len(x[0]))
         path_info = environ.get('PATH_INFO', '')
         for prefix, app in apps:
             if not path_info.startswith(prefix):
                 continue
             environ['SCRIPT_NAME'] = environ.get('SCRIPT_NAME', '')+prefix
             environ['PATH_INFO'] = environ.get('PATH_INFO', 
'')[len(prefix):]
             return app(environ, start_response)
         start_response('404 Not Found', [('Content-type', 'text/html')])
         return ['<html><body><h1>Not Found</h1></body></html>']


There's a bunch of checks that should take place (most related to /'s), 
and the not found response should be configurable (probably as an 
application that can be passed in as an argument).  But that's most of 
what it should do.


-- 
Ian Bicking  /  ianb at colorstudy.com  /  http://blog.ianbicking.org

From pje at telecommunity.com  Fri Apr 28 22:16:43 2006
From: pje at telecommunity.com (Phillip J. Eby)
Date: Fri, 28 Apr 2006 16:16:43 -0400
Subject: [Web-SIG] [Python-Dev]  Adding wsgiref to stdlib
In-Reply-To: <44526DD3.4010807@colorstudy.com>
References: <ca471dc20604281103o3cc9ea5fnd7e03dd724f7b0b0@mail.gmail.com>
	<ca471dc20604281103o3cc9ea5fnd7e03dd724f7b0b0@mail.gmail.com>
Message-ID: <5.1.1.6.0.20060428160624.04234328@mail.telecommunity.com>

At 02:32 PM 4/28/2006 -0500, Ian Bicking wrote:
>Guido van Rossum wrote:
> > PEP 333 specifies WSGI, the Python Web Server Gateway Interface v1.0;
> > it's written by Phillip Eby who put a lot of effort in it to make it
> > acceptable to very diverse web frameworks. The PEP has been well
> > received by web framework makers and users.
> >
> > As a supplement to the PEP, Phillip has written a reference
> > implementation, "wsgiref". I don't know how many people have used
> > wsgiref; I'm using it myself for an intranet webserver and am very
> > happy with it. (I'm asking Phillip to post the URL for the current
> > source; searching for it produces multiple repositories.)
> >
> > I believe that it would be a good idea to add wsgiref to the stdlib,
> > after some minor cleanups such as removing the extra blank lines that
> > Phillip puts in his code. Having standard library support will remove
> > the last reason web framework developers might have to resist adopting
> > WSGI, and the resulting standardization will help web framework users.
>
>I'd like to include paste.lint with that as well (as wsgiref.lint or
>whatever).  Since the last discussion I enumerated in the docstring all
>the checks it does.  There's still some outstanding issues, mostly where
>I'm not sure if it is too restrictive (marked with @@ in the source).
>It's at:
>
>    http://svn.pythonpaste.org/Paste/trunk/paste/lint.py

+1, but lose the unused 'global_conf' parameter and 'make_middleware' 
functions.


>I think another useful addition would be some prefix-based dispatcher,
>similar to paste.urlmap (but probably a bit simpler):
>http://svn.pythonpaste.org/Paste/trunk/paste/urlmap.py

I'd rather see something a *lot* simpler - something that just takes a 
dictionary mapping names to application objects, and parses path segments 
using wsgiref functions.  That way, its usefulness as an example wouldn't 
be obscured by having too many features.  Such a thing would still be quite 
useful, and would illustrate how to do more sophisticated 
dispatching.  Something more or less like:

     from wsgiref.util import shift_path_info

     # usage:
     #    main_app = AppMap(foo=part_one, bar=part_two, ...)

     class AppMap:
         def __init__(self, **apps):
             self.apps = apps

         def __call__(self, environ, start_response):
             name = shift_path_info(environ)
             if name is None:
                 return self.default(environ, start_response)
             elif name in self.apps:
                 return self.apps[name](environ,start_response)
             return self.not_found(environ, start_response)

         def default(self, environ, start_response):
             self.not_found(environ, start_response)

         def not_found(self, environ, start_response):
             # code to generate a 404 response here

This should be short enough to highlight the concept, while still providing 
a few hooks for subclassing.


From guido at python.org  Fri Apr 28 22:19:26 2006
From: guido at python.org (Guido van Rossum)
Date: Fri, 28 Apr 2006 13:19:26 -0700
Subject: [Web-SIG] Adding wsgiref to stdlib
In-Reply-To: <44527506.2070407@colorstudy.com>
References: <ca471dc20604281103o3cc9ea5fnd7e03dd724f7b0b0@mail.gmail.com>
	<44526DD3.4010807@colorstudy.com>
	<ca471dc20604281247k23a586aayd1b7f1c9241e782a@mail.gmail.com>
	<44527506.2070407@colorstudy.com>
Message-ID: <ca471dc20604281319n544a4d9o13febc927266f2fd@mail.gmail.com>

It still looks like an application of WSGI, not part of a reference
implementation. Multiple apps looks like an advanced topic to me; more
something that the infrastructure (Apache server or whatever) ought to
take care of.

I don't expect you to agree with me. But I don't expect you to be able
to convince me either. Maybe you can convince Phillip; I'm going to
try to sit on my hands now.

--Guido

On 4/28/06, Ian Bicking <ianb at colorstudy.com> wrote:
> Guido van Rossum wrote:
> >> I think another useful addition would be some prefix-based dispatcher,
> >> similar to paste.urlmap (but probably a bit simpler):
> >> http://svn.pythonpaste.org/Paste/trunk/paste/urlmap.py
> >
> >
> > IMO this is getting into framework design. Perhaps something like this
> > could be added in 2.6?
>
> I don't think it's frameworky.  It could be used to build a very
> primitive framework, but even then it's not a particularly useful
> starting point.
>
> In Paste this would generally be used below any framework (or above I
> guess, depending on which side is "up").  You'd pass /blog to a blog
> app, /cms to a cms app, etc.  WSGI already is very specific about what
> needs to be done when doing this dispatching (adjusting SCRIPT_NAME and
> PATH_INFO), and that's all that the dispatching needs to do.
>
> The applications themselves are written in some framework with internal
> notions of URL dispatching, but this doesn't infringe upon those.
> (Unless the framework doesn't respect SCRIPT_NAME and PATH_INFO; but
> that's their problem, as the dispatcher is just using what's already
> allowed for in the WSGI spec.)  It also doesn't overlap with frameworks,
> as prefix-based dispatching isn't really that useful in a framework.
>
> The basic implementation is:
>
> class PrefixDispatch(object):
>      def __init__(self):
>          self.applications = {}
>      def add_application(self, prefix, app):
>          self.applications[prefix] = app
>      def __call__(self, environ, start_response):
>          apps = sorted(self.applications.items(),
>                        key=lambda x: -len(x[0]))
>          path_info = environ.get('PATH_INFO', '')
>          for prefix, app in apps:
>              if not path_info.startswith(prefix):
>                  continue
>              environ['SCRIPT_NAME'] = environ.get('SCRIPT_NAME', '')+prefix
>              environ['PATH_INFO'] = environ.get('PATH_INFO',
> '')[len(prefix):]
>              return app(environ, start_response)
>          start_response('404 Not Found', [('Content-type', 'text/html')])
>          return ['<html><body><h1>Not Found</h1></body></html>']
>
>
> There's a bunch of checks that should take place (most related to /'s),
> and the not found response should be configurable (probably as an
> application that can be passed in as an argument).  But that's most of
> what it should do.
>
>
> --
> Ian Bicking  /  ianb at colorstudy.com  /  http://blog.ianbicking.org
>


--
--Guido van Rossum (home page: http://www.python.org/~guido/)

From ianb at colorstudy.com  Fri Apr 28 22:31:08 2006
From: ianb at colorstudy.com (Ian Bicking)
Date: Fri, 28 Apr 2006 15:31:08 -0500
Subject: [Web-SIG] Adding wsgiref to stdlib
In-Reply-To: <ca471dc20604281319n544a4d9o13febc927266f2fd@mail.gmail.com>
References: <ca471dc20604281103o3cc9ea5fnd7e03dd724f7b0b0@mail.gmail.com>	
	<44526DD3.4010807@colorstudy.com>	
	<ca471dc20604281247k23a586aayd1b7f1c9241e782a@mail.gmail.com>	
	<44527506.2070407@colorstudy.com>
	<ca471dc20604281319n544a4d9o13febc927266f2fd@mail.gmail.com>
Message-ID: <44527B8C.8030809@colorstudy.com>

Guido van Rossum wrote:
> It still looks like an application of WSGI, not part of a reference
> implementation. Multiple apps looks like an advanced topic to me; more
> something that the infrastructure (Apache server or whatever) ought to
> take care of.

I don't understand the distinction between "application of WSGI" and 
"reference implementation".  The reference implementation *is* an 
application of WSGI... using the reference implementation doesn't make 
something more or less WSGI.

Also, wsgiref *is* infrastructure.  When using the HTTP server, there is 
no other infrastructure, there is nothing else that will do this prefix 
dispatching for you.

Apache and other web servers also provides this functionality, and with 
the right configuration it will provide the identical environment as a 
prefix dispatcher.  To me that's a positive.  I've seen cases where 
other people have done the same prefix dispatching in Python *without* 
matching the interface of anybody else's code or environment; that's the 
sort of thing a reference implementation is meant to keep people from doing.


-- 
Ian Bicking  /  ianb at colorstudy.com  /  http://blog.ianbicking.org

From pje at telecommunity.com  Fri Apr 28 22:41:25 2006
From: pje at telecommunity.com (Phillip J. Eby)
Date: Fri, 28 Apr 2006 16:41:25 -0400
Subject: [Web-SIG] Adding wsgiref to stdlib
In-Reply-To: <ca471dc20604281319n544a4d9o13febc927266f2fd@mail.gmail.com
 >
References: <44527506.2070407@colorstudy.com>
	<ca471dc20604281103o3cc9ea5fnd7e03dd724f7b0b0@mail.gmail.com>
	<44526DD3.4010807@colorstudy.com>
	<ca471dc20604281247k23a586aayd1b7f1c9241e782a@mail.gmail.com>
	<44527506.2070407@colorstudy.com>
Message-ID: <5.1.1.6.0.20060428163524.037e5fb8@mail.telecommunity.com>

At 01:19 PM 4/28/2006 -0700, Guido van Rossum wrote:
>It still looks like an application of WSGI, not part of a reference
>implementation. Multiple apps looks like an advanced topic to me; more
>something that the infrastructure (Apache server or whatever) ought to
>take care of.

I'm fine with a super-simple implementation that emphasizes the concept, 
not feature-richness.  A simple dict-based implementation showcases both 
the wsgiref function for path shifting, and the idea of composing an 
application out of mini-applications.  (The point is to demonstrate how 
people can compose WSGI applications *without* needing a framework.)

But I don't think that this demo should be a prefix mapper; people doing 
more sophisticated routing can use Paste or Routes.

If it's small enough, I'd say to add this mapper to wsgiref.util, or if 
Guido is strongly set against it being in the code, we should at least put 
it in the documentation as an example of how to use 'shift_path_info()' in 
wsgiref.util.


From guido at python.org  Fri Apr 28 22:40:01 2006
From: guido at python.org (Guido van Rossum)
Date: Fri, 28 Apr 2006 13:40:01 -0700
Subject: [Web-SIG] Adding wsgiref to stdlib
In-Reply-To: <5.1.1.6.0.20060428163524.037e5fb8@mail.telecommunity.com>
References: <ca471dc20604281103o3cc9ea5fnd7e03dd724f7b0b0@mail.gmail.com>
	<44526DD3.4010807@colorstudy.com>
	<ca471dc20604281247k23a586aayd1b7f1c9241e782a@mail.gmail.com>
	<44527506.2070407@colorstudy.com>
	<5.1.1.6.0.20060428163524.037e5fb8@mail.telecommunity.com>
Message-ID: <ca471dc20604281340y7f9dbee7i1adf3e6c74922443@mail.gmail.com>

On 4/28/06, Phillip J. Eby <pje at telecommunity.com> wrote:
> If it's small enough, I'd say to add this mapper to wsgiref.util, or if
> Guido is strongly set against it being in the code, we should at least put
> it in the documentation as an example of how to use 'shift_path_info()' in
> wsgiref.util.

I'm for doing what you think is best.

--
--Guido van Rossum (home page: http://www.python.org/~guido/)

From ianb at colorstudy.com  Fri Apr 28 22:50:59 2006
From: ianb at colorstudy.com (Ian Bicking)
Date: Fri, 28 Apr 2006 15:50:59 -0500
Subject: [Web-SIG] [Python-Dev]  Adding wsgiref to stdlib
In-Reply-To: <5.1.1.6.0.20060428160624.04234328@mail.telecommunity.com>
References: <ca471dc20604281103o3cc9ea5fnd7e03dd724f7b0b0@mail.gmail.com>
	<ca471dc20604281103o3cc9ea5fnd7e03dd724f7b0b0@mail.gmail.com>
	<5.1.1.6.0.20060428160624.04234328@mail.telecommunity.com>
Message-ID: <44528033.5080506@colorstudy.com>

Phillip J. Eby wrote:
>> I'd like to include paste.lint with that as well (as wsgiref.lint or
>> whatever).  Since the last discussion I enumerated in the docstring all
>> the checks it does.  There's still some outstanding issues, mostly where
>> I'm not sure if it is too restrictive (marked with @@ in the source).
>> It's at:
>>
>>    http://svn.pythonpaste.org/Paste/trunk/paste/lint.py
> 
> 
> +1, but lose the unused 'global_conf' parameter and 'make_middleware' 
> functions.

Yeah, those are just related to Paste Deploy and wouldn't go in.

>> I think another useful addition would be some prefix-based dispatcher,
>> similar to paste.urlmap (but probably a bit simpler):
>> http://svn.pythonpaste.org/Paste/trunk/paste/urlmap.py
> 
> 
> I'd rather see something a *lot* simpler - something that just takes a 
> dictionary mapping names to application objects, and parses path 
> segments using wsgiref functions.  That way, its usefulness as an 
> example wouldn't be obscured by having too many features.  Such a thing 
> would still be quite useful, and would illustrate how to do more 
> sophisticated dispatching.  Something more or less like:
> 
>     from wsgiref.util import shift_path_info
> 
>     # usage:
>     #    main_app = AppMap(foo=part_one, bar=part_two, ...)
> 
>     class AppMap:
>         def __init__(self, **apps):
>             self.apps = apps
> 
>         def __call__(self, environ, start_response):
>             name = shift_path_info(environ)
>             if name is None:
>                 return self.default(environ, start_response)
>             elif name in self.apps:
>                 return self.apps[name](environ,start_response)
>             return self.not_found(environ, start_response)
> 
>         def default(self, environ, start_response):
>             self.not_found(environ, start_response)
> 
>         def not_found(self, environ, start_response):
>             # code to generate a 404 response here
> 
> This should be short enough to highlight the concept, while still 
> providing a few hooks for subclassing.

That's mostly what I was thinking, though using a full prefix (instead 
of just a single path segment), and the default is the application at 
'', like in my other email.

paste.urlmap has several features I wouldn't propose (like domain and 
port matching, more Paste Deploy stuff, and a proxy object that I should 
probably just delete); I probably should have been more specific. 
URLMap's dictionary interface isn't that useful either.

Another feature that the example in my other email doesn't have is / 
handling, specifically redirecting /something-that-matches to 
/something-that-matches/ (something Apache's Alias doesn't do but should).

Host and port matching is pretty easy to do at the same time, and in my 
experience can be useful to do at the same time, but I don't really care 
if that feature goes in.

-- 
Ian Bicking  /  ianb at colorstudy.com  /  http://blog.ianbicking.org

From p.f.moore at gmail.com  Fri Apr 28 22:52:32 2006
From: p.f.moore at gmail.com (Paul Moore)
Date: Fri, 28 Apr 2006 21:52:32 +0100
Subject: [Web-SIG] WSGI Server implementation which runs as a Windows service
Message-ID: <79990c6b0604281352x4960fb70j64de923945cd03c9@mail.gmail.com>

I'm starting to play with WSGI, and I'd really like to find a
reasonable WSGI server implementation which will run as a Windows
service. I had a go with the CherryPy (2.2.1) WSGI server, and it
didn't seem to play nicely with the standard run-cherrypy-as-a-service
code I've used before. I may have been doing something wrong -
pointers gratefully accepted if so, but I'm equally open to other
options.

My basic reason is to get away from mod_python - I'd like to have a
WSGI server service, which serves my various web applications, and
just use Apache as a proxy. Mounting WSGI apps on a single service
seems likely to be a much easier approach than wrapping every
application into a service with its own port, etc, etc.

Thanks for any pointers,
Paul.

From guido at python.org  Fri Apr 28 23:00:16 2006
From: guido at python.org (Guido van Rossum)
Date: Fri, 28 Apr 2006 14:00:16 -0700
Subject: [Web-SIG] WSGI Server implementation which runs as a Windows
	service
In-Reply-To: <79990c6b0604281352x4960fb70j64de923945cd03c9@mail.gmail.com>
References: <79990c6b0604281352x4960fb70j64de923945cd03c9@mail.gmail.com>
Message-ID: <ca471dc20604281400j58a250deu54ad136bed5d424@mail.gmail.com>

Support for Windows services is part of win32all, not core Python.

--Guido

On 4/28/06, Paul Moore <p.f.moore at gmail.com> wrote:
> I'm starting to play with WSGI, and I'd really like to find a
> reasonable WSGI server implementation which will run as a Windows
> service. I had a go with the CherryPy (2.2.1) WSGI server, and it
> didn't seem to play nicely with the standard run-cherrypy-as-a-service
> code I've used before. I may have been doing something wrong -
> pointers gratefully accepted if so, but I'm equally open to other
> options.
>
> My basic reason is to get away from mod_python - I'd like to have a
> WSGI server service, which serves my various web applications, and
> just use Apache as a proxy. Mounting WSGI apps on a single service
> seems likely to be a much easier approach than wrapping every
> application into a service with its own port, etc, etc.
>
> Thanks for any pointers,
> Paul.
> _______________________________________________
> 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/guido%40python.org
>


--
--Guido van Rossum (home page: http://www.python.org/~guido/)

From ianb at colorstudy.com  Fri Apr 28 23:04:28 2006
From: ianb at colorstudy.com (Ian Bicking)
Date: Fri, 28 Apr 2006 16:04:28 -0500
Subject: [Web-SIG] Adding wsgiref to stdlib
In-Reply-To: <5.1.1.6.0.20060428163524.037e5fb8@mail.telecommunity.com>
References: <44527506.2070407@colorstudy.com>
	<ca471dc20604281103o3cc9ea5fnd7e03dd724f7b0b0@mail.gmail.com>
	<44526DD3.4010807@colorstudy.com>
	<ca471dc20604281247k23a586aayd1b7f1c9241e782a@mail.gmail.com>
	<44527506.2070407@colorstudy.com>
	<5.1.1.6.0.20060428163524.037e5fb8@mail.telecommunity.com>
Message-ID: <4452835C.7080902@colorstudy.com>

Phillip J. Eby wrote:
> At 01:19 PM 4/28/2006 -0700, Guido van Rossum wrote:
> 
>> It still looks like an application of WSGI, not part of a reference
>> implementation. Multiple apps looks like an advanced topic to me; more
>> something that the infrastructure (Apache server or whatever) ought to
>> take care of.
> 
> 
> I'm fine with a super-simple implementation that emphasizes the concept, 
> not feature-richness.  A simple dict-based implementation showcases both 
> the wsgiref function for path shifting, and the idea of composing an 
> application out of mini-applications.  (The point is to demonstrate how 
> people can compose WSGI applications *without* needing a framework.)
> 
> But I don't think that this demo should be a prefix mapper; people doing 
> more sophisticated routing can use Paste or Routes.

I don't see why not to use prefix matching.  It is more consistent with 
the handling of the default application ('', instead of a method that 
needs to be overridden), and more general, and the algorithm is only 
barely more complex and not what I'd call sophisticated.  The default 
application handling in particular means that AppMap isn't really useful 
without subclassing or assigning to .default.

Prefix matching wouldn't show off anything else in wsgiref, because 
there's nothing else to use; paste.urlmap doesn't use any other part of 
Paste either (except one unimportant exception) because there's just no 
need.


-- 
Ian Bicking  /  ianb at colorstudy.com  /  http://blog.ianbicking.org

From pje at telecommunity.com  Fri Apr 28 23:49:09 2006
From: pje at telecommunity.com (Phillip J. Eby)
Date: Fri, 28 Apr 2006 17:49:09 -0400
Subject: [Web-SIG] WSGI Server implementation which runs as a Windows
 service
In-Reply-To: <ca471dc20604281400j58a250deu54ad136bed5d424@mail.gmail.com
 >
References: <79990c6b0604281352x4960fb70j64de923945cd03c9@mail.gmail.com>
	<79990c6b0604281352x4960fb70j64de923945cd03c9@mail.gmail.com>
Message-ID: <5.1.1.6.0.20060428174712.01e4e4a8@mail.telecommunity.com>

FYI, Paul, I think Guido mistook your message as being in the "adding 
wsgiref to the stdlib"  thread.  :)

As for your question, I think there's an IIS WSGI implementation.  It's 
also possible that Twisted or Zope have WSGI servers suitable for use as a 
Windows service.


At 02:00 PM 4/28/2006 -0700, Guido van Rossum wrote:
>Support for Windows services is part of win32all, not core Python.
>
>--Guido
>
>On 4/28/06, Paul Moore <p.f.moore at gmail.com> wrote:
> > I'm starting to play with WSGI, and I'd really like to find a
> > reasonable WSGI server implementation which will run as a Windows
> > service. I had a go with the CherryPy (2.2.1) WSGI server, and it
> > didn't seem to play nicely with the standard run-cherrypy-as-a-service
> > code I've used before. I may have been doing something wrong -
> > pointers gratefully accepted if so, but I'm equally open to other
> > options.
> >
> > My basic reason is to get away from mod_python - I'd like to have a
> > WSGI server service, which serves my various web applications, and
> > just use Apache as a proxy. Mounting WSGI apps on a single service
> > seems likely to be a much easier approach than wrapping every
> > application into a service with its own port, etc, etc.


From pje at telecommunity.com  Fri Apr 28 23:52:11 2006
From: pje at telecommunity.com (Phillip J. Eby)
Date: Fri, 28 Apr 2006 17:52:11 -0400
Subject: [Web-SIG] [Python-Dev]  Adding wsgiref to stdlib
In-Reply-To: <4452835C.7080902@colorstudy.com>
References: <5.1.1.6.0.20060428163524.037e5fb8@mail.telecommunity.com>
	<44527506.2070407@colorstudy.com>
	<ca471dc20604281103o3cc9ea5fnd7e03dd724f7b0b0@mail.gmail.com>
	<44526DD3.4010807@colorstudy.com>
	<ca471dc20604281247k23a586aayd1b7f1c9241e782a@mail.gmail.com>
	<44527506.2070407@colorstudy.com>
	<5.1.1.6.0.20060428163524.037e5fb8@mail.telecommunity.com>
Message-ID: <5.1.1.6.0.20060428174915.01fab7f8@mail.telecommunity.com>

At 04:04 PM 4/28/2006 -0500, Ian Bicking wrote:
>I don't see why not to use prefix matching.  It is more consistent with
>the handling of the default application ('', instead of a method that
>needs to be overridden), and more general, and the algorithm is only
>barely more complex and not what I'd call sophisticated.  The default
>application handling in particular means that AppMap isn't really useful
>without subclassing or assigning to .default.
>
>Prefix matching wouldn't show off anything else in wsgiref,

Right, that would be taking away one of the main reasons to include it.

To make the real dispatcher, I'd flesh out what I wrote a little bit, to 
handle the "default" method in a more meaningful way, including the 
redirect.  All that should only add a few lines, however.


From p.f.moore at gmail.com  Fri Apr 28 23:50:20 2006
From: p.f.moore at gmail.com (Paul Moore)
Date: Fri, 28 Apr 2006 22:50:20 +0100
Subject: [Web-SIG] WSGI Server implementation which runs as a Windows
	service
In-Reply-To: <ca471dc20604281400j58a250deu54ad136bed5d424@mail.gmail.com>
References: <79990c6b0604281352x4960fb70j64de923945cd03c9@mail.gmail.com>
	<ca471dc20604281400j58a250deu54ad136bed5d424@mail.gmail.com>
Message-ID: <79990c6b0604281450m75bcb44bnb6501c3ae5ddb044@mail.gmail.com>

On 4/28/06, Guido van Rossum <guido at python.org> wrote:
> Support for Windows services is part of win32all, not core Python.

Sorry, I don't think I made my request clear. I'm looking for WSGI
server implementations, and in particular ones which can be made to
work as Windows services. The service side of things I know how to do,
it's the WSGI implementation I'm looking for.

I'll try the CherryPy list to see if they can help. There's folks on
there who know about getting the main CherryPy server working as a
service, they might be able to help with the WSGI one. I'll worry
about other servers if/when I find I can't get anywhere with CP.

Paul.

From ianb at colorstudy.com  Sat Apr 29 00:47:55 2006
From: ianb at colorstudy.com (Ian Bicking)
Date: Fri, 28 Apr 2006 17:47:55 -0500
Subject: [Web-SIG] [Python-Dev]  Adding wsgiref to stdlib
In-Reply-To: <5.1.1.6.0.20060428174915.01fab7f8@mail.telecommunity.com>
References: <5.1.1.6.0.20060428163524.037e5fb8@mail.telecommunity.com>
	<44527506.2070407@colorstudy.com>
	<ca471dc20604281103o3cc9ea5fnd7e03dd724f7b0b0@mail.gmail.com>
	<44526DD3.4010807@colorstudy.com>
	<ca471dc20604281247k23a586aayd1b7f1c9241e782a@mail.gmail.com>
	<44527506.2070407@colorstudy.com>
	<5.1.1.6.0.20060428163524.037e5fb8@mail.telecommunity.com>
	<5.1.1.6.0.20060428174915.01fab7f8@mail.telecommunity.com>
Message-ID: <44529B9B.6050805@colorstudy.com>

Phillip J. Eby wrote:
> At 04:04 PM 4/28/2006 -0500, Ian Bicking wrote:
> 
>> I don't see why not to use prefix matching.  It is more consistent with
>> the handling of the default application ('', instead of a method that
>> needs to be overridden), and more general, and the algorithm is only
>> barely more complex and not what I'd call sophisticated.  The default
>> application handling in particular means that AppMap isn't really useful
>> without subclassing or assigning to .default.
>>
>> Prefix matching wouldn't show off anything else in wsgiref,
> 
> 
> Right, that would be taking away one of the main reasons to include it.

That's putting the cart in front of the horse, using a matching 
algorithm because that's what shift_path_info does, not because it's the 
most natural or useful way to do the match.

I suggest prefix matching not because it shows how the current functions 
in wsgiref work, but because it shows a pattern of dispatching WSGI 
applications on a level that is typically (but for WSGI, unnecessarily) 
built into the server.  The educational value is in the pattern, not in 
the implementation.

If you want to show how the functions in wsgiref work, then that belongs 
in documentation.  Which would be good too, people like examples, and 
the more examples in the wsgiref docs the better.  People are much less 
likely to see examples in the code itself.

> To make the real dispatcher, I'd flesh out what I wrote a little bit, to 
> handle the "default" method in a more meaningful way, including the 
> redirect.  All that should only add a few lines, however.

It will still be only a couple lines less than prefix matching.

Another issue with your implementation is the use of keyword arguments 
for the path mappings, even though path mappings have no association 
with keyword arguments or valid Python identifiers.

-- 
Ian Bicking  /  ianb at colorstudy.com  /  http://blog.ianbicking.org

From titus at caltech.edu  Sat Apr 29 01:34:35 2006
From: titus at caltech.edu (Titus Brown)
Date: Fri, 28 Apr 2006 16:34:35 -0700
Subject: [Web-SIG] [Python-Dev] Adding wsgiref to stdlib
In-Reply-To: <5.1.1.6.0.20060428142518.01e2b180@mail.telecommunity.com>
References: <ca471dc20604281103o3cc9ea5fnd7e03dd724f7b0b0@mail.gmail.com>
	<5.1.1.6.0.20060428142518.01e2b180@mail.telecommunity.com>
Message-ID: <20060428233435.GC22737@caltech.edu>

On Fri, Apr 28, 2006 at 02:36:11PM -0400, Phillip J. Eby wrote:
-> At 11:03 AM 4/28/2006 -0700, Guido van Rossum wrote:
-> >(I'm asking Phillip to post the URL for the current
-> >source; searching for it produces multiple repositories.)
-> 
-> Source browsing: http://svn.eby-sarna.com/wsgiref/
-> Anonymous SVN:   svn://svn.eby-sarna.com/svnroot/wsgiref

Hi, Phillip,

I'm getting this error when I run the tests, with both Python 2.3 and
2.4:

======================================================================
FAIL: testHeaderFormats (wsgiref.tests.test_handlers.HandlerTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/disk/u/t/dev/misc/wsgiref/src/wsgiref/tests/test_handlers.py", line 205, in testHeaderFormats
    (stdpat%(version,sw), h.stdout.getvalue())
AssertionError: ('HTTP/1.0 200 OK\\r\\nDate: \\w{3} \\w{3} [ 0123]\\d \\d\\d:\\d\\d:\\d\\d \\d{4}\\r\\nServer: FooBar/1.0\r\nContent-Length: 0\\r\\n\\r\\n', 'HTTP/1.0 200 OK\r\nDate: Fri, 28 Apr 2006 23:28:11 GMT\r\nServer: FooBar/1.0\r\nContent-Length: 0\r\n\r\n')

----------------------------------------------------------------------

On a separate note, what are you actually proposing to include?  It'd be
good to remove the TODO list, for example, unless those are things To Be
Done before adding it into Python 2.5.

Will it be added as 'wsgi' or 'wsgiref?

I'd also personally suggest putting anything intended for common use
directly under the top level, i.e.

	wsgiref.WSGIServer

vs

	wsgiref.simple_server.WSGIServer

And, finally, is there any documentation?

I'm happy to help with renaming, doc writing, etc.  Just point me in the
right direction!

cheers,
--titus

From pje at telecommunity.com  Sat Apr 29 01:48:58 2006
From: pje at telecommunity.com (Phillip J. Eby)
Date: Fri, 28 Apr 2006 19:48:58 -0400
Subject: [Web-SIG] [Python-Dev]  Adding wsgiref to stdlib
In-Reply-To: <44529B9B.6050805@colorstudy.com>
References: <5.1.1.6.0.20060428174915.01fab7f8@mail.telecommunity.com>
	<5.1.1.6.0.20060428163524.037e5fb8@mail.telecommunity.com>
	<44527506.2070407@colorstudy.com>
	<ca471dc20604281103o3cc9ea5fnd7e03dd724f7b0b0@mail.gmail.com>
	<44526DD3.4010807@colorstudy.com>
	<ca471dc20604281247k23a586aayd1b7f1c9241e782a@mail.gmail.com>
	<44527506.2070407@colorstudy.com>
	<5.1.1.6.0.20060428163524.037e5fb8@mail.telecommunity.com>
	<5.1.1.6.0.20060428174915.01fab7f8@mail.telecommunity.com>
Message-ID: <5.1.1.6.0.20060428193927.01e30ec8@mail.telecommunity.com>

At 05:47 PM 4/28/2006 -0500, Ian Bicking wrote:
>It will still be only a couple lines less than prefix matching.

That's beside the point.  Prefix matching is inherently a more complex 
concept, and more likely to be confusing, without introducing much in the 
way of new features.  If I want to dispatch /foo/bar, why not just use:

     AppMap(foo=AppMap(bar=whatever))


So, I don't see prefix matching as introducing anything that's worth the 
extra complexity.  If somebody needs a high-performance prefix matcher, 
they can get yours from Paste.

If I was going to include a more sophisticated dispatcher, I'd add an 
ordered regular expression dispatcher, since that would support use cases 
that the simple or prefix dispatchers would not, but it would also support 
the prefix cases without nesting.


>Another issue with your implementation is the use of keyword arguments for 
>the path mappings, even though path mappings have no association with 
>keyword arguments or valid Python identifiers.

That was for brevity; it should probably also take a mapping argument.


From pje at telecommunity.com  Sat Apr 29 01:57:33 2006
From: pje at telecommunity.com (Phillip J. Eby)
Date: Fri, 28 Apr 2006 19:57:33 -0400
Subject: [Web-SIG] [Python-Dev] Adding wsgiref to stdlib
In-Reply-To: <20060428233435.GC22737@caltech.edu>
References: <5.1.1.6.0.20060428142518.01e2b180@mail.telecommunity.com>
	<ca471dc20604281103o3cc9ea5fnd7e03dd724f7b0b0@mail.gmail.com>
	<5.1.1.6.0.20060428142518.01e2b180@mail.telecommunity.com>
Message-ID: <5.1.1.6.0.20060428195148.042cff48@mail.telecommunity.com>

At 04:34 PM 4/28/2006 -0700, Titus Brown wrote:
>Hi, Phillip,
>
>I'm getting this error when I run the tests, with both Python 2.3 and
>2.4:
>
>======================================================================
>FAIL: testHeaderFormats (wsgiref.tests.test_handlers.HandlerTests)
>----------------------------------------------------------------------
>Traceback (most recent call last):
>   File "/disk/u/t/dev/misc/wsgiref/src/wsgiref/tests/test_handlers.py", 
> line 205, in testHeaderFormats
>     (stdpat%(version,sw), h.stdout.getvalue())
>AssertionError: ('HTTP/1.0 200 OK\\r\\nDate: \\w{3} \\w{3} [ 0123]\\d 
>\\d\\d:\\d\\d:\\d\\d \\d{4}\\r\\nServer: FooBar/1.0\r\nContent-Length: 
>0\\r\\n\\r\\n', 'HTTP/1.0 200 OK\r\nDate: Fri, 28 Apr 2006 23:28:11 
>GMT\r\nServer: FooBar/1.0\r\nContent-Length: 0\r\n\r\n')
>
>----------------------------------------------------------------------

This is probably due to Guido's patch to make the Date: header more RFC 
compliant.  I'll take a look at it this weekend.


>On a separate note, what are you actually proposing to include?  It'd be
>good to remove the TODO list, for example, unless those are things To Be
>Done before adding it into Python 2.5.

Well, it looks like the "validate" bit will be going in, and we're talking 
about what to put in "router", so that'll take care of half the list right 
there.  :)

The other two items can wait, unless somebody wants to contribute them.



>Will it be added as 'wsgi' or 'wsgiref?

I assumed it would be wsgiref, which would allow compatibility with 
existing code that uses it.


>I'd also personally suggest putting anything intended for common use
>directly under the top level, i.e.
>
>         wsgiref.WSGIServer
>
>vs
>
>         wsgiref.simple_server.WSGIServer

I'm against this, because it would force the handlers and simple_server 
modules to be imported, even for programs not using them.


>And, finally, is there any documentation?

Only the docstrings.  Contributions are more than welcome.



From ianb at colorstudy.com  Sat Apr 29 02:48:42 2006
From: ianb at colorstudy.com (Ian Bicking)
Date: Fri, 28 Apr 2006 19:48:42 -0500
Subject: [Web-SIG] [Python-Dev]  Adding wsgiref to stdlib
In-Reply-To: <5.1.1.6.0.20060428193927.01e30ec8@mail.telecommunity.com>
References: <5.1.1.6.0.20060428174915.01fab7f8@mail.telecommunity.com>
	<5.1.1.6.0.20060428163524.037e5fb8@mail.telecommunity.com>
	<44527506.2070407@colorstudy.com>
	<ca471dc20604281103o3cc9ea5fnd7e03dd724f7b0b0@mail.gmail.com>
	<44526DD3.4010807@colorstudy.com>
	<ca471dc20604281247k23a586aayd1b7f1c9241e782a@mail.gmail.com>
	<44527506.2070407@colorstudy.com>
	<5.1.1.6.0.20060428163524.037e5fb8@mail.telecommunity.com>
	<5.1.1.6.0.20060428174915.01fab7f8@mail.telecommunity.com>
	<5.1.1.6.0.20060428193927.01e30ec8@mail.telecommunity.com>
Message-ID: <4452B7EA.8060707@colorstudy.com>

Phillip J. Eby wrote:
> At 05:47 PM 4/28/2006 -0500, Ian Bicking wrote:
>> It will still be only a couple lines less than prefix matching.
> 
> That's beside the point.  Prefix matching is inherently a more complex 
> concept, and more likely to be confusing, without introducing much in 
> the way of new features.  

I just don't understand this.  It's not more complex.  Prefix matching 
works like:

   get the prefixes
   order them longest first
   check each one against PATH_INFO
   use the matched app
   or call the not found handler

Name matching works like:

   get the mapping
   get the next chunk
   get the app associated with that chunk
   use that app
   or call the not found handler

One is not more complex than the other.


> If I want to dispatch /foo/bar, why not just use:
> 
>     AppMap(foo=AppMap(bar=whatever))

You create an intermediate application with no particular purpose.  You 
get two default handlers, two not found handlers, and you create an 
object tree that is distracting because it is artificial.  Paths are 
strings, not trees or objects.  When you confuse strings for objects you 
are moving into framework territory.

> If I was going to include a more sophisticated dispatcher, I'd add an 
> ordered regular expression dispatcher, since that would support use 
> cases that the simple or prefix dispatchers would not, but it would also 
> support the prefix cases without nesting.

That is significantly more complex, because SCRIPT_NAME/PATH_INFO cannot 
be used to express what the regular expression matched.  It also 
overlaps with frameworks.  WSGI doesn't offer any standard mechanism to 
do that sort of thing.  It could (e.g., a wsgi.path_vars key), but it 
doesn't.  Or you do something that looks like mod_rewrite, but no one 
wants that.

Prefix based routing represents a real cusp -- more than that, and you 
have to invent conventions not already present in the WSGI spec, and you 
overlap with frameworks.  Less than that... well, you can't do a whole 
lot less than that.

-- 
Ian Bicking  |  ianb at colorstudy.com  |  http://blog.ianbicking.org

From pje at telecommunity.com  Sat Apr 29 04:26:49 2006
From: pje at telecommunity.com (Phillip J. Eby)
Date: Fri, 28 Apr 2006 22:26:49 -0400
Subject: [Web-SIG] [Python-Dev]  Adding wsgiref to stdlib
In-Reply-To: <4452B7EA.8060707@colorstudy.com>
References: <5.1.1.6.0.20060428193927.01e30ec8@mail.telecommunity.com>
	<5.1.1.6.0.20060428174915.01fab7f8@mail.telecommunity.com>
	<5.1.1.6.0.20060428163524.037e5fb8@mail.telecommunity.com>
	<44527506.2070407@colorstudy.com>
	<ca471dc20604281103o3cc9ea5fnd7e03dd724f7b0b0@mail.gmail.com>
	<44526DD3.4010807@colorstudy.com>
	<ca471dc20604281247k23a586aayd1b7f1c9241e782a@mail.gmail.com>
	<44527506.2070407@colorstudy.com>
	<5.1.1.6.0.20060428163524.037e5fb8@mail.telecommunity.com>
	<5.1.1.6.0.20060428174915.01fab7f8@mail.telecommunity.com>
	<5.1.1.6.0.20060428193927.01e30ec8@mail.telecommunity.com>
Message-ID: <5.1.1.6.0.20060428221439.01e31ea0@mail.telecommunity.com>

At 07:48 PM 4/28/2006 -0500, Ian Bicking wrote:
>One is not more complex than the other.

The implementation has more moving parts, but I was talking about 
conceptual complexity.

The most common web servers do not match path prefixes, they have 
directories and files.  You can't have /foo/bar without a /foo.  I see 
little value in implementing a system where you *can* have /foo/bar without 
a /foo.  HTTP URLs are inherently and explicitly hierarchical; they aren't 
arbitrary strings that happen to have slashes in them, which is what prefix 
matching treats them as.


>Paths are
>strings, not trees or objects.  When you confuse strings for objects you
>are moving into framework territory.

Quite the reverse, actually.  When you confuse URL paths for strings, 
you're just misunderstanding HTTP.  If you don't believe me, read the HTTP 
and URI RFCs.  I don't think that such confusion should be embedded in 
wsgiref, let alone the stdlib.


From janssen at parc.com  Sat Apr 29 09:09:14 2006
From: janssen at parc.com (Bill Janssen)
Date: Sat, 29 Apr 2006 00:09:14 PDT
Subject: [Web-SIG] Adding wsgiref to stdlib
In-Reply-To: Your message of "Fri, 28 Apr 2006 13:19:26 PDT."
	<ca471dc20604281319n544a4d9o13febc927266f2fd@mail.gmail.com> 
Message-ID: <06Apr29.000917pdt."58641"@synergy1.parc.xerox.com>

> It still looks like an application of WSGI, not part of a reference
> implementation.

It seems to me that canonical exemplars are part of what a "reference"
implementation should include.  Otherwise it would be a "standard"
implementation, which is considerably different.

Bill


From janssen at parc.com  Sat Apr 29 09:13:08 2006
From: janssen at parc.com (Bill Janssen)
Date: Sat, 29 Apr 2006 00:13:08 PDT
Subject: [Web-SIG] [Python-Dev]  Adding wsgiref to stdlib
In-Reply-To: Your message of "Fri, 28 Apr 2006 13:47:38 PDT."
	<43aa6ff70604281347l6c58366egaab182a91aa12420@mail.gmail.com> 
Message-ID: <06Apr29.001312pdt."58641"@synergy1.parc.xerox.com>

> Perhaps this could go in Demo/wsgiref/?

Perhaps both Ian's and Phillip's examples could go into Demo/wsgiref/?

Bill

From ianb at colorstudy.com  Sun Apr 30 02:50:37 2006
From: ianb at colorstudy.com (Ian Bicking)
Date: Sat, 29 Apr 2006 19:50:37 -0500
Subject: [Web-SIG] [Python-Dev]  Adding wsgiref to stdlib
In-Reply-To: <5.1.1.6.0.20060428221439.01e31ea0@mail.telecommunity.com>
References: <5.1.1.6.0.20060428193927.01e30ec8@mail.telecommunity.com>
	<5.1.1.6.0.20060428174915.01fab7f8@mail.telecommunity.com>
	<5.1.1.6.0.20060428163524.037e5fb8@mail.telecommunity.com>
	<44527506.2070407@colorstudy.com>
	<ca471dc20604281103o3cc9ea5fnd7e03dd724f7b0b0@mail.gmail.com>
	<44526DD3.4010807@colorstudy.com>
	<ca471dc20604281247k23a586aayd1b7f1c9241e782a@mail.gmail.com>
	<44527506.2070407@colorstudy.com>
	<5.1.1.6.0.20060428163524.037e5fb8@mail.telecommunity.com>
	<5.1.1.6.0.20060428174915.01fab7f8@mail.telecommunity.com>
	<5.1.1.6.0.20060428193927.01e30ec8@mail.telecommunity.com>
	<5.1.1.6.0.20060428221439.01e31ea0@mail.telecommunity.com>
Message-ID: <445409DD.2090304@colorstudy.com>

Phillip J. Eby wrote:
> At 07:48 PM 4/28/2006 -0500, Ian Bicking wrote:
>> One is not more complex than the other.
> 
> The implementation has more moving parts, but I was talking about 
> conceptual complexity.
> 
> The most common web servers do not match path prefixes, they have 
> directories and files.  You can't have /foo/bar without a /foo.  I see 
> little value in implementing a system where you *can* have /foo/bar 
> without a /foo.  HTTP URLs are inherently and explicitly hierarchical; 
> they aren't arbitrary strings that happen to have slashes in them, which 
> is what prefix matching treats them as.

Apache matches prefixes with Alias.  It does not require directories, it 
doesn't care about the existence of intermediate directories.  It 
doesn't even care about slashes (though I find that behavior unhelpful). 
  From what I can tell Lighttpd uses regex matching on the path, so it 
doesn't treat / as special.  Xitami also seems to just be a path.

Because applications use PATH_INFO in whatever way they want, there is 
no way to know if "/foo" exists.  If / exist, then /foo exists, even 
though it may return a 404.  If you have an app at /, and an app at 
/private/cms, then perhaps /private is served by the application at /. 
The matcher doesn't know, and doesn't need to know.

Prefix matching is how web servers work, and for good reason.  Let's 
just stick with the conventional implementation.


-- 
Ian Bicking  |  ianb at colorstudy.com  |  http://blog.ianbicking.org

From grahamd at dscpl.com.au  Sun Apr 30 08:40:37 2006
From: grahamd at dscpl.com.au (Graham Dumpleton)
Date: Sun, 30 Apr 2006 16:40:37 +1000
Subject: [Web-SIG] [Python-Dev]  Adding wsgiref to stdlib
In-Reply-To: <445409DD.2090304@colorstudy.com>
References: <5.1.1.6.0.20060428193927.01e30ec8@mail.telecommunity.com>
	<5.1.1.6.0.20060428174915.01fab7f8@mail.telecommunity.com>
	<5.1.1.6.0.20060428163524.037e5fb8@mail.telecommunity.com>
	<44527506.2070407@colorstudy.com>
	<ca471dc20604281103o3cc9ea5fnd7e03dd724f7b0b0@mail.gmail.com>
	<44526DD3.4010807@colorstudy.com>
	<ca471dc20604281247k23a586aayd1b7f1c9241e782a@mail.gmail.com>
	<44527506.2070407@colorstudy.com>
	<5.1.1.6.0.20060428163524.037e5fb8@mail.telecommunity.com>
	<5.1.1.6.0.20060428174915.01fab7f8@mail.telecommunity.com>
	<5.1.1.6.0.20060428193927.01e30ec8@mail.telecommunity.com>
	<5.1.1.6.0.20060428221439.01e31ea0@mail.telecommunity.com>
	<445409DD.2090304@colorstudy.com>
Message-ID: <EF96E1A0-BA44-44C2-9592-1AA0851CA8F9@dscpl.com.au>


On 30/04/2006, at 10:50 AM, Ian Bicking wrote:

> Phillip J. Eby wrote:
>> At 07:48 PM 4/28/2006 -0500, Ian Bicking wrote:
>>> One is not more complex than the other.
>>
>> The implementation has more moving parts, but I was talking about
>> conceptual complexity.
>>
>> The most common web servers do not match path prefixes, they have
>> directories and files.  You can't have /foo/bar without a /foo.  I  
>> see
>> little value in implementing a system where you *can* have /foo/bar
>> without a /foo.  HTTP URLs are inherently and explicitly  
>> hierarchical;
>> they aren't arbitrary strings that happen to have slashes in them,  
>> which
>> is what prefix matching treats them as.
>
> Apache matches prefixes with Alias.  It does not require  
> directories, it
> doesn't care about the existence of intermediate directories.  It
> doesn't even care about slashes (though I find that behavior  
> unhelpful).

Apache does care about slashes at least when it is mapping request
against the filesystem. Specifically, the builtin module mod_dir runs a
handler as last thing in the fixup handler phase and if the URL maps  
to a
directory but the URL doesn't have a trailing slash, then the module
will return a redirect response to force the browser to perform the  
request
again but with a trailing slash.

The problem is that Python based frameworks which use mod_python
as merely a jumping off point tend not to perform this trailing slash
redirection in any meaningful way when mapping URLs against any
sort of Python object structures. Even mod_python.publisher, the layer
provided on top of the mod_python core is flawed in this respect.

Graham