Removal of CherryPy documentation on mod_wsgi site.

[Graham Dumpleton]

I am removing many integration guides which appear on mod_wsgi site
wiki and replacing them with links to any official documentation on
the site the page was about. In others words, in your case to be
replaced with a link to CherryPy documentation on how to use mod_wsgi
with CherryPy.

Can some one please look through:

http://code.google.com/p/modwsgi/wiki/IntegrationWithCherryPy

and copy from it into the CherryPy documentation anything relevant to
your current CherryPy version you may want to preserve and provide me
a link to where in CherryPy documentation mod_wsgi integration is
described.

It may also be relevant to look at:

http://code.google.com/p/modwsgi/issues/detail?id=151

which was a ticket about how the existing documentation was out of
date.

If no one is interested in a link back to CherryPy documentation, then
I'll just remove the page in about a week.

The reason for doing this is that I cannot keep up with how all the
different web frameworks and applications integrate with mod_wsgi, so
any documentation I provide gets out of date. I don't like having
inaccurate documentation, so am thus going to rely on developers of
the web frameworks and applications to maintain their own integration
guides if they support using mod_wsgi.

Thanks.

Graham

[Robert Brewer]

much more than a week ago ;), Graham Dumpleton threatened:

Copied to http://tools.cherrypy.org/wiki/ModWSGI Thanks for your
patience!

Robert Brewer
fuma...@aminus.org

[Graham Dumpleton]

Thanks, and updated as well, which was I was hoping would also happen.
I just can't keep up with what is happening with all the frameworks
these days.

BTW, in respect of CherryPy and Python 3.0, if you haven't seen it
already, what I am doing for Python 3.0 in mod_wsgi 3.0 is documented
in:

http://blog.dscpl.com.au/2009/10/new-release-candidate-for-modwsgi-30-is.html

Graham

[Robert Brewer]

Graham Dumpleton wrote:
> BTW, in respect of CherryPy and Python 3.0, if you haven't seen it
> already, what I am doing for Python 3.0 in mod_wsgi 3.0 is documented
> in:
>
> http://blog.dscpl.com.au/2009/10/new-release-candidate-for-modwsgi-
> 30-is.html

Yup. I've been working all day to get a release candidate ready for 3.2,
which will follow that plan. However, we're also including support for a
"full unicode" version of WSGI which I'm just calling wsgi.version =
('u', 0) since it's obviously not in the linear version history. Last
week I refactored wsgiserver so we can support arbitrary, pluggable WSGI
versions.

Robert Brewer
fuma...@aminus.org

[Graham Dumpleton]

On Oct 4, 5:40 pm, "Robert Brewer" <fuman...@aminus.org> wrote:
> Graham Dumpleton wrote:
> > BTW, in respect of CherryPy and Python 3.0, if you haven't seen it

> > already, what I am doing for Python 3.0 inmod_wsgi3.0 is documented

> > in:
>
> >  http://blog.dscpl.com.au/2009/10/new-release-candidate-for-modwsgi-
> > 30-is.html
>
> Yup. I've been working all day to get a release candidate ready for 3.2,
> which will follow that plan. However, we're also including support for a
> "full unicode" version of WSGI which I'm just calling wsgi.version =
> ('u', 0) since it's obviously not in the linear version history. Last
> week I refactored wsgiserver so we can support arbitrary, pluggable WSGI
> versions.

FWIW, my current feeling is that the additional unicode encoding
conversions shouldn't even be a part of the base WSGI specification.
Which ever of the variants wins, I can see no reason why it shouldn't
be handled as a 'x-wsgiorg' specification like 'routing_args'. Ie.,

http://www.wsgi.org/wsgi/Specifications

Graham