From chad at zetaweb.com  Sat Dec  2 22:45:20 2006
From: chad at zetaweb.com (Chad Whitacre)
Date: Sat, 02 Dec 2006 16:45:20 -0500
Subject: [Web-SIG] [ANN] Aspen 0.4 -- pure WSGI
Message-ID: <4571F3F0.3050207@zetaweb.com>

Dear All,

Aspen is a Python web server that I first released two weeks ago. 
The initial versions used a slight superset of WSGI for their 
extension architecture. In my initial announcement I flagged this 
as a deficiency, and I'm happy to say it's fixed in version 0.4, 
out today:

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

If you haven't yet, check out the screencast and/or the tutorial 
for an introduction. You'll also see that I've set up a Google 
Group for support requests.

Next I hope to focus on secondary considerations like module 
reloading, daemonization, logging, etc. After that I hope to 
build some nifty systems on top of Aspen.

Thanks.



chad

From chad at zetaweb.com  Tue Dec  5 04:54:30 2006
From: chad at zetaweb.com (Chad Whitacre)
Date: Mon, 04 Dec 2006 22:54:30 -0500
Subject: [Web-SIG] [ANN] Aspen 0.5 -- module reloading & directory handlers
Message-ID: <4574ED76.4050203@zetaweb.com>

Hey all,

Another Aspen release today (Aspen is a Python web server). This 
one adds:

   - automatic restart when source files change
   - handlers for directories as well as files

With the latter I've implemented directory browsing as part of 
the default configuration.

My plan is to implement logging and daemonization in version 0.6. 
Then I hope to upgrade a few of my current sites to Aspen 0.6, 
and go from there. I've got some cool virtual hosting ideas, for 
example.

Has anyone else touched this? Can I maybe ask a question? What 
use case do you have that Aspen *might* support but you're not 
sure? Or to put it another way, fill in the blank: "Yes, but can 
it do ___________."

I'm pretty excited about how Aspen is turning out, and I'd love 
any feedback anyone's got, pro or con.

Thanks!



chad

From chad at zetaweb.com  Tue Dec  5 04:55:45 2006
From: chad at zetaweb.com (Chad Whitacre)
Date: Mon, 04 Dec 2006 22:55:45 -0500
Subject: [Web-SIG] Chad is still a dork (was Re: [ANN] Aspen 0.5 -- module
 reloading & directory handlers)
In-Reply-To: <4574ED76.4050203@zetaweb.com>
References: <4574ED76.4050203@zetaweb.com>
Message-ID: <4574EDC1.8090803@zetaweb.com>

> Another Aspen release today (Aspen is a Python web server).

And you can get it here:

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



chad

From luke.arno at gmail.com  Tue Dec  5 21:25:19 2006
From: luke.arno at gmail.com (Luke Arno)
Date: Tue, 5 Dec 2006 15:25:19 -0500
Subject: [Web-SIG] ANN: Vulnerability in Static
Message-ID: <d79e89ce0612051225s5db8ff4enc91136031baa5588@mail.gmail.com>

A serious vulnerability has been discovered in static
allowing access to arbitrary files. Please update to
version 0.3.2 or higher, right away!

Thanks to Jason Kirtland for reporting this.

Cheers,
- Luke

From renesd at gmail.com  Wed Dec  6 01:36:40 2006
From: renesd at gmail.com (=?ISO-8859-1?Q?Ren=E9_Dudfield?=)
Date: Wed, 6 Dec 2006 11:36:40 +1100
Subject: [Web-SIG] [ANN] Aspen 0.5 -- module reloading & directory
	handlers
In-Reply-To: <4574ED76.4050203@zetaweb.com>
References: <4574ED76.4050203@zetaweb.com>
Message-ID: <64ddb72c0612051636j1bdf7c2avaebb79622e37e131@mail.gmail.com>

Why did you make it?  Just for fun?  Or is there some other reason you
chose to make it?


On 12/5/06, Chad Whitacre <chad at zetaweb.com> wrote:
> Hey all,
>
> Another Aspen release today (Aspen is a Python web server). This
> one adds:
>
>    - automatic restart when source files change
>    - handlers for directories as well as files
>
> With the latter I've implemented directory browsing as part of
> the default configuration.
>
> My plan is to implement logging and daemonization in version 0.6.
> Then I hope to upgrade a few of my current sites to Aspen 0.6,
> and go from there. I've got some cool virtual hosting ideas, for
> example.
>
> Has anyone else touched this? Can I maybe ask a question? What
> use case do you have that Aspen *might* support but you're not
> sure? Or to put it another way, fill in the blank: "Yes, but can
> it do ___________."
>
> I'm pretty excited about how Aspen is turning out, and I'd love
> any feedback anyone's got, pro or con.
>
> Thanks!
>
>
>
> chad
> _______________________________________________
> 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/renesd%40gmail.com
>

From chad at zetaweb.com  Wed Dec  6 05:46:42 2006
From: chad at zetaweb.com (Chad Whitacre)
Date: Tue, 05 Dec 2006 23:46:42 -0500
Subject: [Web-SIG] [ANN] Aspen 0.5 -- module reloading &
	directory	handlers
In-Reply-To: <64ddb72c0612051636j1bdf7c2avaebb79622e37e131@mail.gmail.com>
References: <4574ED76.4050203@zetaweb.com>
	<64ddb72c0612051636j1bdf7c2avaebb79622e37e131@mail.gmail.com>
Message-ID: <45764B32.6080006@zetaweb.com>

Ren?,

> Why did you make it?  Just for fun?  Or is there some other reason you
> chose to make it?

Thanks for biting. :-)

Not just for fun, no. I maintain about 30 websites, implemented 
in a mix of server technologies:

   - Apache (static HTML, CGI, PHP)
   - Zope 2 (with and without Plone)
   - httpyd (Aspen fore-runner)

My goal with Aspen is to shove all of this heterogeneity into the 
websites themselves, and use a single server for all of them. I 
named it Aspen because a grove of aspen trees all share a common 
root structure (ranking certain aspen groves among the world's 
largest living things!).

As I mentioned earlier, I think Aspen shares this goal with Paste 
Script/Deploy, but Aspen is more filesystem-centric, it's 
intended for production use, and (IMO) it's simpler.

Here are some design considerations:

   - I want to use a single web server for many heterogeneous
     websites, from development through to production.

   - A website should "look like a website" on the filesystem. Any
     project-y directory structure should be swept under the rug.

   - At the same time, websites should be self-contained, with all
     packages and configuration together in one place.

   - I should be able to type "aspen" in any directory and have
     something smart happen.

   - Configuration syntaxes should be simple and stupid. Python
     especially is waaay overkill as a configuration language.


If Aspen were written in C you could compare it to Mongrel.

I'd be curious to know what you use to build and deploy your WSGI 
websites. Do you use Paste Script/Deploy, or something else?

Thanks again for your questions.



chad

P.S. Paste includes a lot. I actually spent quite a while today 
becoming more familiar with all of Paste's middleware, and I'm 
pretty excited about that part of it. PonyMiddleware! :)

From maheh_saied at yahoo.com  Wed Dec  6 12:55:30 2006
From: maheh_saied at yahoo.com (mahdieh saeed)
Date: Wed, 6 Dec 2006 03:55:30 -0800 (PST)
Subject: [Web-SIG] extension programing with c
Message-ID: <405635.60335.qm@web53613.mail.yahoo.com>

  Hi
  I want to define extention module that connect to berkeley db.
  I define function for connection to berkeley db with c language in one file and define other function for create extention module that can import from python.
   function for connection to berkeley db is like this:
  name=BDB.c
  ---------------------------------------------
  #include <db.h>
void CreateDatabase(char *databasename){
DB *dbp ;
int ret;
DB_ENV *myEnv;
u_int32_t env_flags;
char *databasename;
ret = db_env_create(&myEnv, 0);
if (ret != 0) {
fprintf(stderr, "Error creating env handle: %s\n", db_strerror(ret));
return -1;
}
env_flags = DB_CREATE |DB_INIT_MPOOL;
if((ret = myEnv->open(myEnv,"env55", env_flags , 0))!=0){
fprintf(stderr, "Error open environment: %s\n", db_strerror(ret));
}
db_create(&dbp,myEnv,0);
dbp->open(dbp,NULL,"university",databasename,DB_BTREE,DB_CREATE,0);
}
---------------------------------------------------------------------------------------------------------------
  function for define extention module is like this:
  name=importBDB.c
  ------------------------------------------------------------------------
  #include <Python.h>
#include <db.h>
  void CreateDatabase(char *);
static PyObject
*insert_data(PyObject *self,PyObject *args) {
char *databasename;
if (!PyArg_ParseTuple(args, "s", &databasename)) {
return NULL;
}
CreateDatabase(databasename);
Py_RETURN_NONE;
}
static PyMethodDef data_methods[] = {
{ "data", (PyCFunction)insert_data, METH_VARARGS, NULL },
{ NULL, NULL, 0, NULL }
};
PyMODINIT_FUNC initdata() {
Py_InitModule3("data", data_methods, "My first extension module.");
}
----------------------------------------------------------------------------------------------------------
  my compiler is gcc and compiling it with this command:
   
  gcc -shared -I/usr/local/include/python2.4 -I/usr/local/BerkeleyDB.4.5/include   \ importBDB.c BDB.c \ -L/usr/local/BerkeleyDB.4.5/lib -ldb-4.5 -o insert.so
   
  there is an error occurs like this:
  gcc:  importBDB.c: No such file or directory
gcc:  -L/usr/local/BerkeleyDB.4.5/lib: No such file or directory

  I know problem for compiler please help me
   
  regards
  saeed 

 
---------------------------------
Have a burning question? Go to Yahoo! Answers and get answers from real people who know.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/web-sig/attachments/20061206/dfd3eff7/attachment.htm 

From luke.arno at gmail.com  Thu Dec  7 17:06:15 2006
From: luke.arno at gmail.com (Luke Arno)
Date: Thu, 7 Dec 2006 11:06:15 -0500
Subject: [Web-SIG] ANN: Another Static Security Update
Message-ID: <d79e89ce0612070806gd3751ddnfe9f40a0fe6317d5@mail.gmail.com>

I missed a corner case in the previous update to
static. I apologize for the inconvenience. Please
update to version 0.3.3 or higher, right away!

Cheers,
- Luke

From chad at zetaweb.com  Fri Dec  8 20:51:50 2006
From: chad at zetaweb.com (Chad Whitacre)
Date: Fri, 08 Dec 2006 14:51:50 -0500
Subject: [Web-SIG] [ANN] Aspen 0.6 -- turning towards 1.0 w/ daemonization
Message-ID: <4579C256.7050804@zetaweb.com>

Greetings, program!

I just released v0.6 of Aspen, a Python web server:

   http://www.zetadev.com/software/aspen/#the-goods

This release features daemonization support, with a nice command 
line UI:

   $ aspen start                   # daemon started
   $ aspen stop                    # daemon stopped
   $ aspen
   aspen starting on ('', 8080)    # running in foreground

(Many thanks to Walter D?rwald for his ll.daemon module.)

With this release we are turning our attention away from Aspen as 
a development environment, and towards Aspen as a production web 
server. That means we are pretty much done messing with the 
extension API, and will now concentrate on things like:

   * configuration for production
   * testing
   * documentation
   * security
   * optimization

In particular, I'm excited to have a couple guys on the mailing 
list looking at optimization, with a patch already produced that 
may speed up static file serving by 5x. If you'd like to help us 
make a kickin' Python web server, now is the time to jump in.



chad

From ianb at colorstudy.com  Fri Dec  8 22:21:38 2006
From: ianb at colorstudy.com (Ian Bicking)
Date: Fri, 08 Dec 2006 15:21:38 -0600
Subject: [Web-SIG] [ANN] Aspen 0.5 -- module reloading
	&	directory	handlers
In-Reply-To: <45764B32.6080006@zetaweb.com>
References: <4574ED76.4050203@zetaweb.com>	<64ddb72c0612051636j1bdf7c2avaebb79622e37e131@mail.gmail.com>
	<45764B32.6080006@zetaweb.com>
Message-ID: <4579D762.2080200@colorstudy.com>

Chad Whitacre wrote:
> Ren?,
> 
>> Why did you make it?  Just for fun?  Or is there some other reason you
>> chose to make it?
> 
> Thanks for biting. :-)
> 
> Not just for fun, no. I maintain about 30 websites, implemented 
> in a mix of server technologies:
> 
>    - Apache (static HTML, CGI, PHP)
>    - Zope 2 (with and without Plone)
>    - httpyd (Aspen fore-runner)
> 
> My goal with Aspen is to shove all of this heterogeneity into the 
> websites themselves, and use a single server for all of them. I 
> named it Aspen because a grove of aspen trees all share a common 
> root structure (ranking certain aspen groves among the world's 
> largest living things!).
> 
> As I mentioned earlier, I think Aspen shares this goal with Paste 
> Script/Deploy, but Aspen is more filesystem-centric, it's 
> intended for production use, and (IMO) it's simpler.

Of course Paste is intended for production use!  But maybe you mean 
paste.httpserver -- which is used some in production cases, but isn't 
entirely intended as such.  Not that we'd turn down patches to improve 
it, but serious testing in typical production situations hasn't really 
been done.

As for simplicity, well, I dunno but it depends a lot on what you are 
talking about.  Of course Paste is many things, but those things are 
loosely bound.

> Here are some design considerations:
> 
>    - I want to use a single web server for many heterogeneous
>      websites, from development through to production.

Paste is essentially web server agnostic.  paste.httpserver is often 
useful in development, but it's really no more bound to Paste than 
anything else.  *All* paste.httpserver does is HTTP, which is important 
IMHO -- by keeping its functionality at a minimum it is more feasible to 
choose other options when there's a reason to do so.  If Aspen sought to 
provide a more production-read HTTP server then that'd be great.

>    - A website should "look like a website" on the filesystem. Any
>      project-y directory structure should be swept under the rug.
> 
>    - At the same time, websites should be self-contained, with all
>      packages and configuration together in one place.

I personally deal with that at the Python level, with tools like 
workingenv and virtual-python.  Anyone doing serious web development 
should definitely be using tools like that, and not installing stuff in 
their system Python.

>    - I should be able to type "aspen" in any directory and have
>      something smart happen.

I really can't predict what that would do...?  That doesn't seem simple 
to me.  It starts up a web server serving the current directory, I 
guess, but with what configuration?  What port, what logging, etc?

>    - Configuration syntaxes should be simple and stupid. Python
>      especially is waaay overkill as a configuration language.

Paste Deploy tries to keep configuration fairly simple.


> If Aspen were written in C you could compare it to Mongrel.
> 
> I'd be curious to know what you use to build and deploy your WSGI 
> websites. Do you use Paste Script/Deploy, or something else?

Right now I'm working in a different kind of development from you (more 
one big website), but previously I was probably in a very similar 
situation with lots of different clients sharing a machine but not 
sharing websites, with some shared applications and code but a lot of 
client-specific code too.

I guess I never actually described what we did there, but it took a 
while to find a good technique and it wasn't really finished before I left.

Because our sites had all been started in Apache (using SSIs for 
templating) we had an Apache frontend and often lots of complex config 
built up over time.  Each site had its own Apache instance and 
configuration (we didn't do virtual hosting).

To incorporate dynamic content we used rewrite rules and later 
ScriptAlias to send certain URLs to an external app server.  We used 
SCGI via cgi2scgi, and we just passed the full URL.

 From there we had a map from URLs to config files.  It looks like:

   [app:main]
   use = egg:Paste#urlmap
   /app1 = config:app1.ini
   /app2 = config:app2.ini (and so on)
   /some/other/app = config:other_app.ini

The name (e.g., "app1") showed up in a lot of places, and while we could 
change the name (e.g., /app1 = config:some_app.ini) we never did.  I 
think you filesystem layout could simplify that some.  But we often had 
reasons to point deep directories to some application point without 
handling the intermediate directories through the app server.

The config files then point to a WSGI application, which is probably 
similar to a handler in Aspen.  Usually there was only one instance of 
the application in a site; we could do more, but that was only used in a 
couple circumstances (though we were moving more in that direction as we 
reconsidered our expectations of what an application could do).  A 
really simple one, for instance, was something that picked a random URL 
from a text file (usually for image rotation):

   [app:main]
   use = egg:Randomize
   file = /path/to/file.txt

We'd put all the instances in one config file, with different sections 
for each case.

The static files were always kept very separate from the code files. 
Sometimes our code would write to static files, though usually not.

For templating we had a search path for templates.  The search path 
generally looked like:

   webhome/templates/app_name/template_name.pt
   webhome/templates/template_name.pt
   apphome/templates/template_name.pt

This let us distribute default templates with each app, with 
app-template or site-template overrides.  We used this a lot for 
client-specific tweaks.  Any other tweaks we'd typically facilitate 
through adding configuration options; we tried not to branch the code 
for very long.  Again, templates never got mixed with static content, 
and client-specific templates never got mixed with the generic 
application.  Everything went into version control, but in different trees.

While putting code in the site directly doesn't seem *horrible* to me, 
once we all learned the techniques of indirection I think keeping code 
separate from data (and data separate from templates) was extremely 
helpful.  We were probably a bigger team than what you're in, and so we 
had people who would only touch static content and templates and never 
code, or people who would only access static content through management 
tools.  So in part our layout reflected the way we split up jobs between 
people.

If I were going to do a filesystem-oriented layout, I'd want to at least 
have a parent directory of the site and not entirely mix static and 
dynamic content.  If nothing else it makes the svn layout easier to 
manage when sharing code (and if you aren't using version control, you 
are of course nuts ;).  Then I'd probably allow a small number of 
special files to cause different kinds of indirection, very similar to 
.htaccess (but of course much nicer than htaccess).

For instance, what if I wanted to allow people to upload files to a 
directory, but didn't trust the people?  I wouldn't want to put any file 
in that directory to indicate this, because I'm afraid someone would 
figure out a way to overwrite that file.  Given a totally representative 
filesystem layout this seems hard to implement.  With just a little 
indirection it's much more feasible.

That said, it would have been awesome to be able to just drop files in 
trusted locations and have functionality just appear.  We never really 
pursued this because we were still using Apache, though I guess if we 
were clever we could have figured it out with some rewrite rules or with 
AddHandler.  Keeping the extension out of the URL would have been 
problematic, though, and I hate code-specific extensions.  (Resource 
specific extensions don't bother me at all, though, like .html).

Hrm... I didn't really mean to go into all that description.  But there 
it is.  I probably should write it up for real sometime.

> Thanks again for your questions.
> 
> 
> 
> chad
> 
> P.S. Paste includes a lot. I actually spent quite a while today 
> becoming more familiar with all of Paste's middleware, and I'm 
> pretty excited about that part of it. PonyMiddleware! :)

And now you are even a contributor to that middleware ;)

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

From sesquile at gmail.com  Fri Dec  8 23:08:16 2006
From: sesquile at gmail.com (m h)
Date: Fri, 8 Dec 2006 15:08:16 -0700
Subject: [Web-SIG] [ANN] Aspen 0.6 -- turning towards 1.0 w/
	daemonization
In-Reply-To: <4579C256.7050804@zetaweb.com>
References: <4579C256.7050804@zetaweb.com>
Message-ID: <e36b84ee0612081408j3564e9aeta7aae856da1f0e89@mail.gmail.com>

On 12/8/06, Chad Whitacre <chad at zetaweb.com> wrote:
> Greetings, program!
Greetings, Chad!
snip...

> With this release we are turning our attention away from Aspen as
> a development environment, and towards Aspen as a production web
> server. That means we are pretty much done messing with the
> extension API, and will now concentrate on things like:
>
>    * configuration for production

A few questions:

Has there been any thought given to dealing with virtual hosting?

Reverse proxy?

Since this is WSGI based, can I deploy it under mod_python or say
fcgi?  Or twisted?

Do you have any stats on how static performance is compared with say
plain old apache?

-thanks

Matt

From chad at zetaweb.com  Sat Dec  9 01:22:51 2006
From: chad at zetaweb.com (Chad Whitacre)
Date: Fri, 8 Dec 2006 19:22:51 -0500
Subject: [Web-SIG] [ANN] Aspen 0.6 -- turning towards 1.0 w/
	daemonization
In-Reply-To: <e36b84ee0612081408j3564e9aeta7aae856da1f0e89@mail.gmail.com>
References: <4579C256.7050804@zetaweb.com>
	<e36b84ee0612081408j3564e9aeta7aae856da1f0e89@mail.gmail.com>
Message-ID: <f593a5ce0612081622k11d30685va04064da8a38170c@mail.gmail.com>

Matt,

Thanks for your questions!


Has there been any thought given to dealing with virtual hosting?


Yes. I hope to implement that as an Aspen application. Basically, my idea is
to put all virtually hosted websites in a directory, /usr/local/www say, and
start a main Aspen process in that dir which would maintain an Aspen child
process for each subdir/website. The main process would then proxy to its
children based on the Host header. Waddya think?


Reverse proxy?


With Aspen in which role, the proxy or the origin server? The above is
basically a reverse proxy (no?); Aspen could of course be proxied itself
behind Apache or Varnish or whatever.


Since this is WSGI based, can I deploy it under mod_python or say
> fcgi?  Or twisted?


Aspen is intended to be deployed in production all on its own. If you'd like
to deploy it otherwise, the place to start is the aspen.website.Websiteclass:

  http://aspen.googlecode.com/svn/tags/0.6/src/aspen/website.py

Unfortunately, the Python API will probably be the last thing documented,
sorry. :-/ Feel free to ask questions, probably on the aspen-users mailing
list:

  http://groups-beta.google.com/group/aspen-users/topics


Do you have any stats on how static performance is compared with say
> plain old apache?
>

There's a couple threads on this on the aspen-users list. The bottom line is
that Aspen is, um, slower than Apache at serving static content. :-)  You'll
notice, though, that we do have a patch for this already (thanks Giorgi!),
which may give us a 5x speed-up for static content. I haven't reviewed the
patch yet, and would be interested in any review or benchmarks you could
provide. :-)

In general, the 1.0 release is focused on the API. If Aspen succeeds, I
expect some parts will eventually be rewritten in C, but first things first.

Thanks again for your feedback!



chad
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/web-sig/attachments/20061208/88651ddf/attachment.htm 

From chad at zetaweb.com  Sat Dec  9 01:30:10 2006
From: chad at zetaweb.com (Chad Whitacre)
Date: Fri, 8 Dec 2006 19:30:10 -0500
Subject: [Web-SIG] [ANN] Aspen 0.5 -- module reloading & directory
	handlers
In-Reply-To: <4579D762.2080200@colorstudy.com>
References: <4574ED76.4050203@zetaweb.com>
	<64ddb72c0612051636j1bdf7c2avaebb79622e37e131@mail.gmail.com>
	<45764B32.6080006@zetaweb.com> <4579D762.2080200@colorstudy.com>
Message-ID: <f593a5ce0612081630g44bf87d9r3ae4c99c88866a53@mail.gmail.com>

> >    - I should be able to type "aspen" in any directory and have
> >      something smart happen.
>
> I really can't predict what that would do...?  That doesn't seem simple
> to me.  It starts up a web server serving the current directory, I
> guess, but with what configuration?  What port, what logging, etc?

So there's an interesting question: with a first impression, what
would ya'll expect this to do? I'd love to know if I got it right. :-)



chad

From chad at zetaweb.com  Sat Dec  9 01:27:51 2006
From: chad at zetaweb.com (Chad Whitacre)
Date: Fri, 8 Dec 2006 19:27:51 -0500
Subject: [Web-SIG] [ANN] Aspen 0.5 -- module reloading & directory
	handlers
In-Reply-To: <4579D762.2080200@colorstudy.com>
References: <4574ED76.4050203@zetaweb.com>
	<64ddb72c0612051636j1bdf7c2avaebb79622e37e131@mail.gmail.com>
	<45764B32.6080006@zetaweb.com> <4579D762.2080200@colorstudy.com>
Message-ID: <f593a5ce0612081627t907b7a7ve387d9bb0e371e1a@mail.gmail.com>

> > P.S. Paste includes a lot. I actually spent quite a while today
> > becoming more familiar with all of Paste's middleware, and I'm
> > pretty excited about that part of it. PonyMiddleware! :)
>
> And now you are even a contributor to that middleware ;)

UNICORN POWER!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!1

:-D

From ianb at colorstudy.com  Sat Dec  9 01:54:04 2006
From: ianb at colorstudy.com (Ian Bicking)
Date: Fri, 08 Dec 2006 18:54:04 -0600
Subject: [Web-SIG] [ANN] Aspen 0.5 -- module reloading & directory
	handlers
In-Reply-To: <f593a5ce0612081630g44bf87d9r3ae4c99c88866a53@mail.gmail.com>
References: <4574ED76.4050203@zetaweb.com>	
	<64ddb72c0612051636j1bdf7c2avaebb79622e37e131@mail.gmail.com>	
	<45764B32.6080006@zetaweb.com> <4579D762.2080200@colorstudy.com>
	<f593a5ce0612081630g44bf87d9r3ae4c99c88866a53@mail.gmail.com>
Message-ID: <457A092C.3010403@colorstudy.com>

Chad Whitacre wrote:
>> >    - I should be able to type "aspen" in any directory and have
>> >      something smart happen.
>>
>> I really can't predict what that would do...?  That doesn't seem simple
>> to me.  It starts up a web server serving the current directory, I
>> guess, but with what configuration?  What port, what logging, etc?
> 
> So there's an interesting question: with a first impression, what
> would ya'll expect this to do? I'd love to know if I got it right. :-)

I guess I'd expect it to look for a server config file in the current 
directory, with some standard filename (e.g., aspen.conf), and then 
start a server in the foreground.  Or maybe I'd expect it to act like 
apachectl, and control an existing process.

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

From chad at zetaweb.com  Sat Dec  9 03:35:55 2006
From: chad at zetaweb.com (Chad Whitacre)
Date: Fri, 08 Dec 2006 21:35:55 -0500
Subject: [Web-SIG] Paste and Aspen (was Re: [ANN] Aspen 0.5 -- module
 reloading & directory handlers)
In-Reply-To: <4579D762.2080200@colorstudy.com>
References: <4574ED76.4050203@zetaweb.com>	<64ddb72c0612051636j1bdf7c2avaebb79622e37e131@mail.gmail.com>
	<45764B32.6080006@zetaweb.com> <4579D762.2080200@colorstudy.com>
Message-ID: <457A210B.1020903@zetaweb.com>

Ian,

Now for some meat. First, thank you for your considered response!


 > Of course Paste is intended for production use!  But maybe you
 > mean paste.httpserver

Yes, that's what I meant, sorry. I understand Paste to be three 
things:

   1. a middleware library
   2. a little web server (Paste Script [paste.httpserver])
   3. a site configuration utility (Paste Deploy)

I love the middleware library! Unicorn power!

Re: the web server: It seems like you threw it together cause 
Apache is too cumbersome for development. It doesn't seem very 
close to the heart of Paste. Is that fair? As far as Aspen goes, 
the core HTTP server is straight outta CherryPy, so I'm not 
really doing anything new there myself. The CherryPy crew wrote a 
dern nice little web server, IMO. :-)


 > Paste Deploy tries to keep configuration fairly simple.

Paste Deploy is where I feel like I'm going to step on toes. 
Honestly, man, I just don't get it. It's not simple to me; it 
doesn't fit my brain.

We could dig into why, but I'm not sure that would be edifying. I 
think the better question is how Aspen might possibly play nice 
as a server for Paste apps. I'm hoping that digging through the 
usage scenarios you described will help me understand Paste more 
and start to answer that question.

Honestly, I'd like to see Aspen become common ground for Python 
web programmers that prefer pure-HTTP deployments, regardless of 
framework. I see cooperation with Paste as a priority in that 
regard, given the number of frameworks that inherit from Paste.


 > I personally deal with that at the Python level, with tools
 > like workingenv and virtual-python.  Anyone doing serious web
 > development should definitely be using tools like that, and not
 > installing stuff in their system Python.

Couldn't agree more. In the screencast I hinted that the magic 
directory is meant to be used in this way when I installed Django 
into it. The possibility of integrating workingenv, etc. into an 
Aspen workflow is on my radar, and I'd love to see that fleshed 
out more.


 > Right now I'm working in a different kind of development from
 > you (more one big website), but previously I was probably in a
 > very similar situation ...

Great info, thanks! It'll take me a while to digest this and 
think about how Aspen might relate. Please stand by ...





chad

From chad at zetaweb.com  Sat Dec  9 03:38:58 2006
From: chad at zetaweb.com (Chad Whitacre)
Date: Fri, 08 Dec 2006 21:38:58 -0500
Subject: [Web-SIG] [ANN] Aspen 0.5 -- module reloading & directory
	handlers
In-Reply-To: <457A092C.3010403@colorstudy.com>
References: <4574ED76.4050203@zetaweb.com>	
	<64ddb72c0612051636j1bdf7c2avaebb79622e37e131@mail.gmail.com>	
	<45764B32.6080006@zetaweb.com> <4579D762.2080200@colorstudy.com>
	<f593a5ce0612081630g44bf87d9r3ae4c99c88866a53@mail.gmail.com>
	<457A092C.3010403@colorstudy.com>
Message-ID: <457A21C2.2060506@zetaweb.com>

Ian Bicking wrote:
> Chad Whitacre wrote:
>>> >    - I should be able to type "aspen" in any directory and have
>>> >      something smart happen.
>>>
>>> I really can't predict what that would do...?  That doesn't seem simple
>>> to me.  It starts up a web server serving the current directory, I
>>> guess, but with what configuration?  What port, what logging, etc?
>>
>> So there's an interesting question: with a first impression, what
>> would ya'll expect this to do? I'd love to know if I got it right. :-)
> 
> I guess I'd expect it to look for a server config file in the current 
> directory, with some standard filename (e.g., aspen.conf), and then 
> start a server in the foreground.  Or maybe I'd expect it to act like 
> apachectl, and control an existing process.
> 

Any other takers on this one?

   $ cd /usr/local/www/example.com
   $ aspen
   ...

What happens next?




chad

From chad at zetaweb.com  Sat Dec  9 19:50:37 2006
From: chad at zetaweb.com (Chad Whitacre)
Date: Sat, 09 Dec 2006 13:50:37 -0500
Subject: [Web-SIG] Virtual hosting in Aspen (was Re: [ANN] Aspen 0.6 --
 turning towards 1.0 w/ daemonization)
In-Reply-To: <e36b84ee0612081652h42bb3668x63235ef50828caeb@mail.gmail.com>
References: <4579C256.7050804@zetaweb.com>	
	<e36b84ee0612081408j3564e9aeta7aae856da1f0e89@mail.gmail.com>	
	<f593a5ce0612081622k11d30685va04064da8a38170c@mail.gmail.com>
	<e36b84ee0612081652h42bb3668x63235ef50828caeb@mail.gmail.com>
Message-ID: <457B057D.7000106@zetaweb.com>

Matt,

>> > Has there been any thought given to dealing with virtual hosting?
>>
>> Yes. I hope to implement that as an Aspen application. Basically, my 
>> idea is to ...

I've sketched out an implementation using paste.proxy, and posted 
it to a new Google Code project called "Aspen Commons:"

   http://aspen-commons.googlecode.com/svn/vhost/


> I'm asking because I'm working on an app that uses apache 2.2 to proxy
> 2 perl apps on apache 1.3 as well as a tomcat and iis app (running on
> a windows machine)...  Just giving a real life example and wondering
> how/where aspen could fit in....

With Aspen you'd instantiate paste.proxy.TransparentProxy for 
each of the four apps, and then wire them up to directory 
locations in __/etc/apps.conf. Your filesystem would look like:

   __/etc/apps.conf
   __/lib/python2.4/proxy.py      <- from paste
   __/lib/python2.4/proxyapps.py  <- yours
   iis/
   perl1/
   perl2/
   tomcat/

The contents of apps.conf would be:

   /iis     proxyapps:iis
   /perl1   proxyapps:perl1
   /perl2   proxyapps:perl2
   /tomcat  proxyapps:tomcat

Does that sound right?



chad

P.S. I had to modify paste.proxy slightly to get it to work.

From sh at defuze.org  Mon Dec 11 20:50:31 2006
From: sh at defuze.org (Sylvain Hellegouarch)
Date: Mon, 11 Dec 2006 19:50:31 +0000
Subject: [Web-SIG] ANN: amplee 0.3.6 - Atom Publishing Protocol
	implementation
Message-ID: <457DB687.9070606@defuze.org>

Hi all,

I'm glad to announce the release of amplee in version 0.3.6

This release is a bug fixes but with a few new features as well:

* Fixed the AtomMember class
* Refactored most of the member internal code
* Fixed a few issues with both the CherryPy and pure WSGI handlers
* Added new examples but separated them from the main distribution.
* Fixed the XHTML member class
* Fixed the storage API issue when listing resources
* Fixed a bug when checking for the existing of a resource
* Moved to support bridge 0.2.1
* Started to add unit tests
* Removed the genser dependency

The API should not have changed a lot apart from specific cases. I hope
this won't break too much code.

I would like to thank David Turner for his great feedback.

== Download ==

 * easy_install -U amplee
 * Tarballs http://www.defuze.org/oss/amplee/
 * svn co https://svn.defuze.org/oss/amplee/

== Documentation ==

http://trac.defuze.org/wiki/amplee
http://www.defuze.org/oss/amplee/doc/html/

== Examples ==

You can get some source code examples at
http://defuze.org/oss/amplee/amplee-examples-0.3.6.tgz

== TODO ==

 * Add more tests
 * Improve documentation

Have fun,
-- Sylvain Hellegouarch
http://www.defuze.org

Reply

From kkinder at gmail.com  Sat Dec 16 02:51:20 2006
From: kkinder at gmail.com (Ken Kinder)
Date: Fri, 15 Dec 2006 18:51:20 -0700
Subject: [Web-SIG] Patch for wsgiref: interrupted connections result in
	close() never being called
Message-ID: <200612151851.20261.kkinder@gmail.com>

If you write a wsgi server that relies on the handler's close() method being 
called for requests, you find out that if the browser disconnects mid-stream, 
close is never called.

The attached patch should be self-explanatory. It fixes this problem.

Thanks
-Ken
-------------- next part --------------
A non-text attachment was scrubbed...
Name: wsgiref-close-not-called.patch
Type: text/x-diff
Size: 1389 bytes
Desc: not available
Url : http://mail.python.org/pipermail/web-sig/attachments/20061215/56a9b858/attachment.bin 

From ianb at colorstudy.com  Sun Dec 17 19:21:37 2006
From: ianb at colorstudy.com (Ian Bicking)
Date: Sun, 17 Dec 2006 12:21:37 -0600
Subject: [Web-SIG] WSGI & CGI spec
Message-ID: <45858AB1.5060404@colorstudy.com>

Reading the CGI spec I'm noticing some requirements it makes that aren't 
done as much in WSGI.

In particular:

6.1.8. QUERY_STRING

    A URL-encoded string; the <query> part of the Script-URI. (See
    section 3.2.)

     QUERY_STRING = query-string
     query-string = *uric

    The URL syntax for a query string is described in section 3 of
    RFC 2396 [4].

    Servers MUST supply this value to scripts. The QUERY_STRING
    value is case-sensitive. If the Script-URI does not include a
    query component, the QUERY_STRING metavariable MUST be defined
    as an empty string ("").


Notice that it is a MUST.  We've already discussed that the cgi module 
acts weird if you don't provide this; but we can go further and say that 
the cgi module is right (well, except for its weird behavior otherwise) 
and anything not providing this is incorrect.

Notably SCRIPT_NAME and PATH_INFO are always required to be present 
(even when empty).  REMOTE_ADDR and SERVER_SOFTWARE are also required 
values.

Lastly it was noted to me that SCRIPT_NAME and PATH_INFO are supposed to 
be decoded (in the spec it says "The syntax and semantics are similar to 
a decoded HTTP URL 'path' token (defined in RFC 2396 [4])").  I haven't 
been doing this, and the spec isn't clear on this (wsgiref does do this 
decoding, as does Apache).  This is to say, when you request 
'/foo%20bar/', PATH_INFO should be '/foo bar/'.

It's also unclear if the WSGI server is expected to normalize the path, 
specifically things like /foo/../bar -- Apache does do this, wsgiref 
does not.  (Is posixpath.normpath good enough to do that?)


Anyway, mostly I think we need some clarifications in the spec.  Though 
the normalization would add an additional requirement to the spec.

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

From ianb at colorstudy.com  Mon Dec 18 06:06:54 2006
From: ianb at colorstudy.com (Ian Bicking)
Date: Sun, 17 Dec 2006 23:06:54 -0600
Subject: [Web-SIG] Paste 1.1
Message-ID: <458621EE.1090602@colorstudy.com>

Paste 1.1
---------

This release includes a security fix, fixing a situation where you
could escape the root when serving static files and running the Paste
HTTP server publicly.  If you used other WSGI servers or used the
Paste HTTP server behind Apache this does not effect you.  For an
update of Paste 1.0 that includes *only* the security fix, use
"easy_install Paste==1.0.1"

What Is Paste?
--------------

URL:     http://pythonpaste.org
Install: easy_install Paste PasteScript PasteDeploy
News: http://pythonpaste.org/news.html
       http://pythonpaste.org/script/news.html
       http://pythonpaste.org/deploy/news.html

Paste is a set of WSGI components, each of which can be used in
isolation.  But used together they form an unstoppable force.  Team
WSGI, unite!

These components let you do things like create applications that proxy
to other websites, mount multiple applications under different
prefixes, catch exceptions and interactively inspect the environment,
and much more.

Paste Deploy is a configuration system for these components.  Paste
Script is a jack of all trades that builds new project file layouts,
runs WSGI server stacks, and does application deployment.

Interesting News
----------------

Paste
~~~~~

* Security fix for paste.urlparser.StaticURLParser.  The problem
   allowed escaping the root (and reading files) when used with
   paste.httpserver (this does not effect other servers, and does
   not apply when proxying requests from Apache to
   paste.httpserver).

* paste.httpserver and paste.fixture.TestApp url-unquote
   SCRIPT_NAME and PATH_INFO, as specified in the CGI spec.
   Thanks to Jon Nelson for pointing out both these issues.

* paste.registry now works within the EvalException
   interactive debugger.

* Added a __traceback_decorator__ magic local variable, to allow
   arbitrary manipulation of the output of
   paste.exceptions.collector before formatting.

* Added unicorn power to paste.pony (from Chad Whitacre)

* For paste.httpserver SSL support: add support loading an
   explicit certificate context, and using ssl_pem='*' create an
   unsigned SSL certificate (from Jason Kirtland).

Paste Script
~~~~~~~~~~~~

* Allow variable assignments at the end of paster serve, like
   paster serve http_port=80; then you can use %(http_port)s in
   your config files (requires up-to-date Paste Deploy).

Paste Deploy
~~~~~~~~~~~~

* Really nothing interesting.

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


From mikeal at osafoundation.org  Tue Dec 19 00:49:05 2006
From: mikeal at osafoundation.org (Mikeal Rogers)
Date: Mon, 18 Dec 2006 15:49:05 -0800
Subject: [Web-SIG] WSGI & CGI spec
In-Reply-To: <45858AB1.5060404@colorstudy.com>
References: <45858AB1.5060404@colorstudy.com>
Message-ID: <DD82B53C-D166-48B4-8656-CD1F51BC613C@osafoundation.org>

> Lastly it was noted to me that SCRIPT_NAME and PATH_INFO are  
> supposed to
> be decoded (in the spec it says "The syntax and semantics are  
> similar to
> a decoded HTTP URL 'path' token (defined in RFC 2396 [4])").  I  
> haven't
> been doing this, and the spec isn't clear on this (wsgiref does do  
> this
> decoding, as does Apache).  This is to say, when you request
> '/foo%20bar/', PATH_INFO should be '/foo bar/'.
>
> It's also unclear if the WSGI server is expected to normalize the  
> path,
> specifically things like /foo/../bar -- Apache does do this, wsgiref
> does not.  (Is posixpath.normpath good enough to do that?)

I've been meaning to bring this up. I wrote a proxy using WSGI and  
recently moved to using the cherrypy wsgi server rather than the one  
in wsgiref.

In wsgiref PATH_INFO is always the full path supplied by the client,  
if the client makes a proxy request and gives the entire uri as the  
path wsgiref doesn't chop it down to _just_ the destination path  
without scheme/host/port/etc (although it does remove the query  
string), while cherrypy does. Looking at the spec it would seem  
cherrypy is correct and this may be a bug in wsgiref.

Using the code sample in PEP 333 I was able to reconstruct the dest  
url in both cases.

-Mikeal

From jason at virtuous.com  Wed Dec 20 00:36:23 2006
From: jason at virtuous.com (Jason Kirtland)
Date: Tue, 19 Dec 2006 15:36:23 -0800
Subject: [Web-SIG] WSGI & CGI spec
In-Reply-To: <45858AB1.5060404@colorstudy.com>
References: <45858AB1.5060404@colorstudy.com>
Message-ID: <2B3AA44CCCA35734FFFBF4B8@[10.8.15.22]>

Ian wrote:
> Reading the CGI spec I'm noticing some requirements it makes that
> aren't done as much in WSGI.
> [...]
> It's also unclear if the WSGI server is expected to normalize the
> path,  specifically things like /foo/../bar -- Apache does do
> this, wsgiref does not.

The spec could definitely use more clarity on the disposition of 
the original request URI.  There's a CGI compatibility requirement 
to supply SCRIPT_NAME and PATH_INFO in the initial environ: 
concepts inseparably linked to selection and execution of an 
executable (RFC 3875, 3.1 - 3.3).  But a WSGI server isn't shaped 
like CGI- all requests funnel through a single callable with no 
inspection of the HTTP Request-URI.  The PEP delegates the request 
routing (i.e. URI analysis) phase to middleware. [1]

To my reading, PEP 333 implies that a server should plop the 
Request-URI into PATH_INFO, and it should store it there 
unmolested.  Any proactive meddling in the URI space is at odds to 
the guideline that a server "play dumb" and act as a transparent 
gateway server.

Allowing the server to normalize into PATH_INFO as a matter of 
course destroys the original Request-URI and makes a whole class of 
raw URI-consuming middleware impossible- no mod_security, no 
filtering of naive spambots, no accurate request logging (!), no 
proxies, etc.  And I see little to gain: URI mapping middleware 
(dynamic or static content serving) isn't going to trust any web 
input anyhow and will implement its own, probably very paranoid, 
normalization.  And really, what URI-sensitive WSGI applications 
are running bare without a mapper?

> (Is posixpath.normpath good enough to do that?)

Note that posixpath.normpath is not Apache compatible. Apache 
leaves empty path segments (//) untouched, normpath prunes empty 
segments.

-Jason

[1] Fronted servers that are invoked from actual CGI, mod_python, 
behind some proxies, etc. play a middleware roll and may have 
implementation-specific access to "current" initial values for 
SCRIPT_NAME/PATH_INFO.


From pje at telecommunity.com  Wed Dec 20 01:19:45 2006
From: pje at telecommunity.com (Phillip J. Eby)
Date: Tue, 19 Dec 2006 19:19:45 -0500
Subject: [Web-SIG] WSGI & CGI spec
In-Reply-To: <2B3AA44CCCA35734FFFBF4B8@[10.8.15.22]>
References: <45858AB1.5060404@colorstudy.com> <45858AB1.5060404@colorstudy.com>
Message-ID: <5.1.1.6.0.20061219191618.02e2cb78@sparrow.telecommunity.com>

At 03:36 PM 12/19/2006 -0800, Jason Kirtland wrote:
>To my reading, PEP 333 implies that a server should plop the
>Request-URI into PATH_INFO, and it should store it there
>unmolested.

That's only the case if the address of the application is the root of the 
server, and then only if the request URI is a path, rather than an absolute 
URI.

Note that a CGI-to-WSGI or FastCGI-to-WSGI gateway (or a piece of routing 
middleware) will have a SCRIPT_NAME that designates the location of the 
target application.  Your reading, in other words, is overly narrow, as it 
applies only to origin servers where the WSGI application represents the 
server's root URI, and thus have an empty SCRIPT_NAME.


From jason at virtuous.com  Wed Dec 20 01:50:15 2006
From: jason at virtuous.com (Jason Kirtland)
Date: Tue, 19 Dec 2006 16:50:15 -0800
Subject: [Web-SIG] WSGI & CGI spec
In-Reply-To: <5.1.1.6.0.20061219191618.02e2cb78@sparrow.telecommunity.com>
References: <45858AB1.5060404@colorstudy.com> <45858AB1.5060404@colorstudy.com>
	<5.1.1.6.0.20061219191618.02e2cb78@sparrow.telecommunity.com>
Message-ID: <40F1F8774F8D2F4C8AEA1128@[10.8.15.22]>

Phillip wrote:
> At 03:36 PM 12/19/2006 -0800, Jason Kirtland wrote:
>> To my reading, PEP 333 implies that a server should plop the
>> Request-URI into PATH_INFO, and it should store it there
>> unmolested.
>
> That's only the case if the address of the application is the
> root of the server, and then only if the request URI is a path,
> rather than an absolute URI.

What would a server do with an absolute URI vs. abs_path, if not 
place it in PATH_INFO?  Or '*', for that matter?  Should these 
types of requests be handleable by a WSGI stack?  Apache augments 
the CGI environment with a REQUEST_URI- if WSGI had one of these I 
guess I'd expect to see non-path URIs there.

> Note that a CGI-to-WSGI or FastCGI-to-WSGI gateway (or a piece of
> routing middleware) will have a SCRIPT_NAME that designates the
> location of the target application.  [...]

Agreed; see the footnote in my post.  A gateway doesn't necessarily 
have or want access to the Request-URI.  I think the anti-fiddling 
assertion applies here as well though- a WSGI gateway server 
shouldn't pro-actively normalize SCRIPT_NAME or PATH_INFO that it's 
pulling from upstream.

-Jason


From pje at telecommunity.com  Wed Dec 20 01:55:30 2006
From: pje at telecommunity.com (Phillip J. Eby)
Date: Tue, 19 Dec 2006 19:55:30 -0500
Subject: [Web-SIG] WSGI & CGI spec
In-Reply-To: <40F1F8774F8D2F4C8AEA1128@[10.8.15.22]>
References: <5.1.1.6.0.20061219191618.02e2cb78@sparrow.telecommunity.com>
	<45858AB1.5060404@colorstudy.com> <45858AB1.5060404@colorstudy.com>
	<5.1.1.6.0.20061219191618.02e2cb78@sparrow.telecommunity.com>
Message-ID: <5.1.1.6.0.20061219195315.046a7008@sparrow.telecommunity.com>

At 04:50 PM 12/19/2006 -0800, Jason Kirtland wrote:
>Phillip wrote:
> > At 03:36 PM 12/19/2006 -0800, Jason Kirtland wrote:
> >> To my reading, PEP 333 implies that a server should plop the
> >> Request-URI into PATH_INFO, and it should store it there
> >> unmolested.
> >
> > That's only the case if the address of the application is the
> > root of the server, and then only if the request URI is a path,
> > rather than an absolute URI.
>
>What would a server do with an absolute URI vs. abs_path, if not
>place it in PATH_INFO?  Or '*', for that matter?

My understanding is that an absolute URI is equivalent to issuing the same 
request with e.g. a 'Host:' header, and should result in equivalent results 
in terms of environment variables.  That is, my understanding is that 
PATH_INFO should *never* contain a URI, rather than a path, and everything 
PEP 333 says about the environment variables is predicated upon that 
assumption.


From pje at telecommunity.com  Wed Dec 20 21:42:56 2006
From: pje at telecommunity.com (Phillip J. Eby)
Date: Wed, 20 Dec 2006 15:42:56 -0500
Subject: [Web-SIG] wsgiref questions
In-Reply-To: <d5bf79c60612201206i7dee0f83v698411bc93db64ed@mail.gmail.co
 m>
References: <5.1.1.6.0.20061220145018.04c8b838@sparrow.telecommunity.com>
	<5.1.1.6.0.20061220145018.04c8b838@sparrow.telecommunity.com>
Message-ID: <5.1.1.6.0.20061220153104.044d1c00@sparrow.telecommunity.com>

At 12:06 PM 12/20/2006 -0800, Guido van Rossum wrote:
>On 12/20/06, Phillip J. Eby <pje at telecommunity.com> wrote:
>>At 10:12 AM 12/20/2006 -0800, Guido van Rossum wrote:
>> >We're struggling to use wsgiref behind some Googlish infrastructure,
>> >and one of the issues we find is that there is code that forbids
>> >hop-by-hop headers. Unfortunately we have a reason to send one
>> >(Transfer-encoding).
>>
>>Are you sure it's not a Content-Encoding?
>
>No, "chunked" is definitely a transfer encoding.
>
>> >  What's the reason behind their prohibition, and
>> >what would be the right way to do this?
>>
>>See the thread here for the original rationale:
>>
>>http://mail.python.org/pipermail/web-sig/2004-September/000879.html
>
>Well, we're using wsgiref's simple_server which only speaks HTTP/1.0,
>but we really need to speak HTTP/1.1 and use chunked. Where do you
>recommend we put the chunking instead?

It's expected that an HTTP/1.1 server would handle chunking in the case 
where a WSGI app yields individual blocks, assuming that the client 
supports chunking and the server chooses to do it that way.  The way the 
spec is written, the server *must* ensure that each yielded chunk is 
transmitted to the client before the application is asked for the next 
chunk.  However, it's the server's choice as to whether the chunks will 
just be streamed or transmitted using chunked encoding.

wsgiref does have this comment at one point in the code (wsgiref.handlers), 
btw:

     # XXX Try for chunked encoding if origin server and client is 1.1

This is the place where you could try to add support for doing this.  I.e., 
that's the place where you'd add the Transfer-Encoding header, after 
checking for client support.

By the way, if your goal is just to ensure that data is written to the 
client as its yielded by the application, that can be done without needing 
the chunked encoding.  My understanding is that all chunked encoding is 
good for is sending data of unknown length over a persistent 
connection.  simple_server doesn't support persistent connections (and WSGI 
doesn't have "connections"), so chunking is of use only if you have some 
crazy kind of client that needs the chunking for some reason known only to 
its developers.  :)


From jason at virtuous.com  Wed Dec 20 21:46:54 2006
From: jason at virtuous.com (Jason Kirtland)
Date: Wed, 20 Dec 2006 12:46:54 -0800
Subject: [Web-SIG] WSGI & CGI spec
In-Reply-To: <5.1.1.6.0.20061219195315.046a7008@sparrow.telecommunity.com>
References: <5.1.1.6.0.20061219191618.02e2cb78@sparrow.telecommunity.
	com> <45858AB1.5060404@colorstudy.com>
	<45858AB1.5060404@colorstudy.com>
	<5.1.1.6.0.20061219191618.02e2cb78@sparrow.telecommunity.com>
	<5.1.1.6.0.20061219195315.046a7008@sparrow.telecommunity.com>
Message-ID: <5FC4454553CF933E3FD66416@[10.8.15.22]>

Phillip wrote:
> At 04:50 PM 12/19/2006 -0800, Jason Kirtland wrote:
>> What would a server do with an absolute URI vs. abs_path, if not
>> place it in PATH_INFO?  Or '*', for that matter?
>
> My understanding is that an absolute URI is equivalent to issuing
> the same request with e.g. a 'Host:' header, and should result in
> equivalent results in terms of environment variables.

An absolute URI request contains more information than a regular 
request- there is an explicit scheme for accessing the URI 
resource.  Moving the scheme to wsgi.url_scheme during a 
normalization is probably not appropriate, as merely requesting an 
absolute URI does not change some basic truths about the request 
(SERVER_PORT, scheme used to issue the overall request, etc.). 
Dropping the scheme on the floor quite possibly changes the meaning 
of the request.



From sh at defuze.org  Wed Dec 20 21:51:34 2006
From: sh at defuze.org (Sylvain Hellegouarch)
Date: Wed, 20 Dec 2006 20:51:34 +0000
Subject: [Web-SIG] wsgiref questions
In-Reply-To: <5.1.1.6.0.20061220153104.044d1c00@sparrow.telecommunity.com>
References: <5.1.1.6.0.20061220145018.04c8b838@sparrow.telecommunity.com>	<5.1.1.6.0.20061220145018.04c8b838@sparrow.telecommunity.com>
	<5.1.1.6.0.20061220153104.044d1c00@sparrow.telecommunity.com>
Message-ID: <4589A256.8050302@defuze.org>


>> Well, we're using wsgiref's simple_server which only speaks HTTP/1.0,
>> but we really need to speak HTTP/1.1 and use chunked. Where do you
>> recommend we put the chunking instead?

<shameless-plug>
If you are not to fuss about which WSGI server you can afford to use,
you could grab the server from CherryPy 3.0 which is HTTP/1.1 fluent.

from cherrypy import wsgiref [1]

You'd be done.
</shameless-plug>

- Sylvain

[1] http://www.cherrypy.org/browser/trunk/cherrypy/wsgiserver.py


From guido at python.org  Wed Dec 20 21:57:29 2006
From: guido at python.org (Guido van Rossum)
Date: Wed, 20 Dec 2006 12:57:29 -0800
Subject: [Web-SIG] wsgiref questions
In-Reply-To: <5.1.1.6.0.20061220153104.044d1c00@sparrow.telecommunity.com>
References: <5.1.1.6.0.20061220145018.04c8b838@sparrow.telecommunity.com>
	<5.1.1.6.0.20061220153104.044d1c00@sparrow.telecommunity.com>
Message-ID: <ca471dc20612201257u66da319fu74148517135bc6a1@mail.gmail.com>

On 12/20/06, Phillip J. Eby <pje at telecommunity.com> wrote:
> At 12:06 PM 12/20/2006 -0800, Guido van Rossum wrote:
> >On 12/20/06, Phillip J. Eby <pje at telecommunity.com> wrote:
> >>At 10:12 AM 12/20/2006 -0800, Guido van Rossum wrote:
> >> >We're struggling to use wsgiref behind some Googlish infrastructure,
> >> >and one of the issues we find is that there is code that forbids
> >> >hop-by-hop headers. Unfortunately we have a reason to send one
> >> >(Transfer-encoding).
> >>
> >>Are you sure it's not a Content-Encoding?
> >
> >No, "chunked" is definitely a transfer encoding.
> >
> >> >  What's the reason behind their prohibition, and
> >> >what would be the right way to do this?
> >>
> >>See the thread here for the original rationale:
> >>
> >>http://mail.python.org/pipermail/web-sig/2004-September/000879.html
> >
> >Well, we're using wsgiref's simple_server which only speaks HTTP/1.0,
> >but we really need to speak HTTP/1.1 and use chunked. Where do you
> >recommend we put the chunking instead?
>
> It's expected that an HTTP/1.1 server would handle chunking in the case
> where a WSGI app yields individual blocks, assuming that the client
> supports chunking and the server chooses to do it that way.  The way the
> spec is written, the server *must* ensure that each yielded chunk is
> transmitted to the client before the application is asked for the next
> chunk.  However, it's the server's choice as to whether the chunks will
> just be streamed or transmitted using chunked encoding.
>
> wsgiref does have this comment at one point in the code (wsgiref.handlers),
> btw:
>
>      # XXX Try for chunked encoding if origin server and client is 1.1
>
> This is the place where you could try to add support for doing this.  I.e.,
> that's the place where you'd add the Transfer-Encoding header, after
> checking for client support.

Yeah, but we'd like not to edit wsgiref, so our code won't depend on a
hacked version of it...

> By the way, if your goal is just to ensure that data is written to the
> client as its yielded by the application, that can be done without needing
> the chunked encoding.  My understanding is that all chunked encoding is
> good for is sending data of unknown length over a persistent
> connection.  simple_server doesn't support persistent connections (and WSGI
> doesn't have "connections"), so chunking is of use only if you have some
> crazy kind of client that needs the chunking for some reason known only to
> its developers.  :)

And guess what, that's exactly the situation we're in.

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

From sh at defuze.org  Wed Dec 20 22:14:23 2006
From: sh at defuze.org (Sylvain Hellegouarch)
Date: Wed, 20 Dec 2006 21:14:23 +0000
Subject: [Web-SIG] wsgiref questions
In-Reply-To: <4589A256.8050302@defuze.org>
References: <5.1.1.6.0.20061220145018.04c8b838@sparrow.telecommunity.com>	<5.1.1.6.0.20061220145018.04c8b838@sparrow.telecommunity.com>	<5.1.1.6.0.20061220153104.044d1c00@sparrow.telecommunity.com>
	<4589A256.8050302@defuze.org>
Message-ID: <4589A7AF.6080404@defuze.org>

Sylvain Hellegouarch wrote:
>>> Well, we're using wsgiref's simple_server which only speaks HTTP/1.0,
>>> but we really need to speak HTTP/1.1 and use chunked. Where do you
>>> recommend we put the chunking instead?
> 
> <shameless-plug>
> If you are not to fuss about which WSGI server you can afford to use,
> you could grab the server from CherryPy 3.0 which is HTTP/1.1 fluent.
> 
> from cherrypy import wsgiref [1]
> 
> You'd be done.
> </shameless-plug>

Because an example is worth all the words:

from cherrypy import wsgiserver

def my_crazy_app(environ, start_response):
    status = '200 OK'
    response_headers = [('Content-type','text/plain')]
    start_response(status, response_headers)
    return ['Hello world!\n']

# This won't call CherryPy machinery at all
# Only the WSGI server which is independant from CherryPy itself
# Its name simply reflects its origin...

server = wsgiserver.CherryPyWSGIServer(('localhost', 8070), [('/',
my_crazy_app)], numthreads=10, server_name='localhost')

# Want SSl support? Just set those attributes
# server.ssl_certificate = ...
# server.ssl_private_key = ...

if __name__ == '__main__':
    server.start()

The nice thing is that you can also support many WSGI applications in
one instance of your server. Anyway only for those who'd be interested ;)

From chad at zetaweb.com  Wed Dec 20 22:28:52 2006
From: chad at zetaweb.com (Chad Whitacre)
Date: Wed, 20 Dec 2006 16:28:52 -0500
Subject: [Web-SIG] wsgiref questions
In-Reply-To: <4589A256.8050302@defuze.org>
References: <5.1.1.6.0.20061220145018.04c8b838@sparrow.telecommunity.com>	<5.1.1.6.0.20061220145018.04c8b838@sparrow.telecommunity.com>	<5.1.1.6.0.20061220153104.044d1c00@sparrow.telecommunity.com>
	<4589A256.8050302@defuze.org>
Message-ID: <4589AB14.8090602@zetaweb.com>

Guido,

>>> Well, we're using wsgiref's simple_server which only speaks HTTP/1.0,
>>> but we really need to speak HTTP/1.1 and use chunked. Where do you
>>> recommend we put the chunking instead?
> 
> <shameless-plug>
> If you are not to fuss about which WSGI server you can afford to use,
> you could grab the server from CherryPy 3.0 which is HTTP/1.1 fluent.

I'll give a +1 to CherryPy's wsgiserver.py module. It's 
well-written, robust, and lightly coupled.

If you're at all interested in a light-weight pure-Python WSGI 
server (rather than a library), you might check out Aspen:

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

CherryPy's module is at the core of Aspen.

If you just want a module, definitely check out CherryPy's.



chad

From pje at telecommunity.com  Wed Dec 20 23:28:04 2006
From: pje at telecommunity.com (Phillip J. Eby)
Date: Wed, 20 Dec 2006 17:28:04 -0500
Subject: [Web-SIG] wsgiref questions
In-Reply-To: <4589A256.8050302@defuze.org>
References: <5.1.1.6.0.20061220153104.044d1c00@sparrow.telecommunity.com>
	<5.1.1.6.0.20061220145018.04c8b838@sparrow.telecommunity.com>
	<5.1.1.6.0.20061220145018.04c8b838@sparrow.telecommunity.com>
	<5.1.1.6.0.20061220153104.044d1c00@sparrow.telecommunity.com>
Message-ID: <5.1.1.6.0.20061220172305.0420ff48@sparrow.telecommunity.com>

At 08:51 PM 12/20/2006 +0000, Sylvain Hellegouarch wrote:

>[1] http://www.cherrypy.org/browser/trunk/cherrypy/wsgiserver.py

Guido, it does appear that this server implements chunked encoding if you:

1. Use a status of 200, 203, or 206
2. Don't include a Content-Length header
3. *Yield* each chunk from your application as a separate block (i.e. don't 
use write())

Sylvain, it appears that the above code has a bug in its chunked support if 
an application uses write() calls.  It will set the encoding to chunked, 
but it won't actually write the data in chunks when write() is called.  You 
might want to pass that information back to the CherryPy developers, 
although I think there are probably some reading this list.


From fumanchu at amor.org  Wed Dec 20 23:44:48 2006
From: fumanchu at amor.org (Robert Brewer)
Date: Wed, 20 Dec 2006 14:44:48 -0800
Subject: [Web-SIG] wsgiref questions
Message-ID: <435DF58A933BA74397B42CDEB8145A8607D4C25F@ex9.hostedexchange.local>

Phillip J. Eby wrote:
> At 08:51 PM 12/20/2006 +0000, Sylvain Hellegouarch wrote:
> 
> >[1] http://www.cherrypy.org/browser/trunk/cherrypy/wsgiserver.py
> 
> Guido, it does appear that this server implements chunked 
> encoding if you:
> 
> 1. Use a status of 200, 203, or 206
> 2. Don't include a Content-Length header
> 3. *Yield* each chunk from your application as a separate 
> block (i.e. don't use write())
> 
> Sylvain, it appears that the above code has a bug in its 
> chunked support if an application uses write() calls.
> It will set the encoding to chunked, but it won't actually
> write the data in chunks when write() is called.  You 
> might want to pass that information back to the CherryPy
> developers, although I think there are probably some
> reading this list.

Thanks. Fixed in http://www.cherrypy.org/changeset/1538.


Robert Brewer
System Architect
Amor Ministries
fumanchu at amor.org

From mark.mchristensen at gmail.com  Wed Dec 20 23:53:36 2006
From: mark.mchristensen at gmail.com (Mark Ramm)
Date: Wed, 20 Dec 2006 17:53:36 -0500
Subject: [Web-SIG] wsgiref questions
In-Reply-To: <435DF58A933BA74397B42CDEB8145A8607D4C25F@ex9.hostedexchange.local>
References: <435DF58A933BA74397B42CDEB8145A8607D4C25F@ex9.hostedexchange.local>
Message-ID: <ec2d68db0612201453g6fb6450eubafa27df3125c19f@mail.gmail.com>

> On 12/20/06 at 5:28 Phillip J. Eby wrote:

> > It will set the encoding to chunked, but it won't actually
> > write the data in chunks when write() is called.  You
> > might want to pass that information back to the CherryPy
> > developers, although I think there are probably some
> > reading this list.

On 12/20/06, at  5:44 Robert Brewer <fumanchu at amor.org> wrote:

> Thanks. Fixed in http://www.cherrypy.org/changeset/1538.

There's a record.  16 min from bug report (on another list no less) to fix.

Color me impressed.

--Mark Ramm-Christensen

From joe at bitworking.org  Wed Dec 20 22:14:00 2006
From: joe at bitworking.org (Joe Gregorio)
Date: Wed, 20 Dec 2006 16:14:00 -0500
Subject: [Web-SIG] WSGI & CGI spec
In-Reply-To: <5.1.1.6.0.20061219195315.046a7008@sparrow.telecommunity.com>
References: <45858AB1.5060404@colorstudy.com>
	<5.1.1.6.0.20061219191618.02e2cb78@sparrow.telecommunity.com>
	<40F1F8774F8D2F4C8AEA1128@10.8.15.22>
	<5.1.1.6.0.20061219195315.046a7008@sparrow.telecommunity.com>
Message-ID: <3f1451f50612201314k1c6618cdi215c7e73481ba198@mail.gmail.com>

On 12/19/06, Phillip J. Eby <pje at telecommunity.com> wrote:
> My understanding is that an absolute URI is equivalent to issuing the same
> request with e.g. a 'Host:' header, and should result in equivalent results
> in terms of environment variables.

Yes, there should be no difference between the
two types of requests.

   -joe

-- 
Joe Gregorio        http://bitworking.org

From jonas at petunial.de  Thu Dec 21 10:17:10 2006
From: jonas at petunial.de (Jonas Weismueller)
Date: Thu, 21 Dec 2006 10:17:10 +0100
Subject: [Web-SIG] petunial - looking for some developers
Message-ID: <458A5116.5060507@petunial.de>

Hi,

we have founded a new project called petunial. We are currently looking
for developers and HTML designer(s). The developers should have
competend knowledge of the Python programming language. The HTML
designers should be good in HTML/CSS but at least some scripting
experiences would be nice too.

More information on petunial can be found on: http://www.petunial.com

Feel free to contact us via mailing list http://petunial.de/#contact or
come along and have a chat on Freenode #petunial with us.
We are looking forward to meeting new people with good team skills to
play well in an open source project to make petunial a better software.

Best regards,

petunial team

From guido at python.org  Thu Dec 21 22:03:37 2006
From: guido at python.org (Guido van Rossum)
Date: Thu, 21 Dec 2006 13:03:37 -0800
Subject: [Web-SIG] wsgiref questions
In-Reply-To: <5.1.1.6.0.20061220172305.0420ff48@sparrow.telecommunity.com>
References: <5.1.1.6.0.20061220145018.04c8b838@sparrow.telecommunity.com>
	<5.1.1.6.0.20061220153104.044d1c00@sparrow.telecommunity.com>
	<4589A256.8050302@defuze.org>
	<5.1.1.6.0.20061220172305.0420ff48@sparrow.telecommunity.com>
Message-ID: <ca471dc20612211303q39e1abbdlcc8443f33534d0ea@mail.gmail.com>

We decided to add chunking encoding to our own server, it wasn't all
that hard. What's the business of only doing it for certain status
codes?

On 12/20/06, Phillip J. Eby <pje at telecommunity.com> wrote:
> At 08:51 PM 12/20/2006 +0000, Sylvain Hellegouarch wrote:
>
> >[1] http://www.cherrypy.org/browser/trunk/cherrypy/wsgiserver.py
>
> Guido, it does appear that this server implements chunked encoding if you:
>
> 1. Use a status of 200, 203, or 206
> 2. Don't include a Content-Length header
> 3. *Yield* each chunk from your application as a separate block (i.e. don't
> use write())
>
> Sylvain, it appears that the above code has a bug in its chunked support if
> an application uses write() calls.  It will set the encoding to chunked,
> but it won't actually write the data in chunks when write() is called.  You
> might want to pass that information back to the CherryPy developers,
> although I think there are probably some reading this list.
>
> _______________________________________________
> 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 fumanchu at amor.org  Thu Dec 21 23:04:55 2006
From: fumanchu at amor.org (Robert Brewer)
Date: Thu, 21 Dec 2006 14:04:55 -0800
Subject: [Web-SIG] wsgiref questions
References: <5.1.1.6.0.20061220145018.04c8b838@sparrow.telecommunity.com><5.1.1.6.0.20061220153104.044d1c00@sparrow.telecommunity.com><4589A256.8050302@defuze.org><5.1.1.6.0.20061220172305.0420ff48@sparrow.telecommunity.com>
	<ca471dc20612211303q39e1abbdlcc8443f33534d0ea@mail.gmail.com>
Message-ID: <435DF58A933BA74397B42CDEB8145A86224CE4@ex9.hostedexchange.local>

Guido van Rossum wrote:
> We decided to add chunking encoding to our own server,
> it wasn't all that hard. What's the business of only
> doing it for certain status codes?

Less overhead if the response has no entity or a small one. In my experience, 200, 203 and 206 are the only ones that have large enough response-bodies to bother. And since there's no spec for a WSGI app to tell a WSGI server to chunk (because chunking support isn't mandatory), it seemed best for a generic server.


Robert Brewer
System Architect
Amor Ministries
fumanchu at amor.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/web-sig/attachments/20061221/0a10c9a9/attachment.htm 

From guido at python.org  Fri Dec 22 00:05:11 2006
From: guido at python.org (Guido van Rossum)
Date: Thu, 21 Dec 2006 15:05:11 -0800
Subject: [Web-SIG] wsgiref questions
In-Reply-To: <435DF58A933BA74397B42CDEB8145A86224CE4@ex9.hostedexchange.local>
References: <5.1.1.6.0.20061220145018.04c8b838@sparrow.telecommunity.com>
	<5.1.1.6.0.20061220153104.044d1c00@sparrow.telecommunity.com>
	<4589A256.8050302@defuze.org>
	<5.1.1.6.0.20061220172305.0420ff48@sparrow.telecommunity.com>
	<ca471dc20612211303q39e1abbdlcc8443f33534d0ea@mail.gmail.com>
	<435DF58A933BA74397B42CDEB8145A86224CE4@ex9.hostedexchange.local>
Message-ID: <ca471dc20612211505wadc09a8jc40f8d2968076799@mail.gmail.com>

Hm, but what would you do with a response not in that list that didn't
have a content-length? You'd have to close the persistent connection.
We're committed to keep the persistent connection open at all times
because there's a special Googly thing at the other end.

On 12/21/06, Robert Brewer <fumanchu at amor.org> wrote:
>
>
>
> Guido van Rossum wrote:
>  > We decided to add chunking encoding to our own server,
>  > it wasn't all that hard. What's the business of only
>  > doing it for certain status codes?
>
>  Less overhead if the response has no entity or a small one. In my
> experience, 200, 203 and 206 are the only ones that have large enough
> response-bodies to bother. And since there's no spec for a WSGI app to tell
> a WSGI server to chunk (because chunking support isn't mandatory), it seemed
> best for a generic server.
>
>
>  Robert Brewer
>  System Architect
>  Amor Ministries
>  fumanchu at amor.org


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

From fumanchu at amor.org  Fri Dec 22 01:06:37 2006
From: fumanchu at amor.org (Robert Brewer)
Date: Thu, 21 Dec 2006 16:06:37 -0800
Subject: [Web-SIG] wsgiref questions
References: <5.1.1.6.0.20061220145018.04c8b838@sparrow.telecommunity.com><5.1.1.6.0.20061220153104.044d1c00@sparrow.telecommunity.com><4589A256.8050302@defuze.org><5.1.1.6.0.20061220172305.0420ff48@sparrow.telecommunity.com><ca471dc20612211303q39e1abbdlcc8443f33534d0ea@mail.gmail.com><435DF58A933BA74397B42CDEB8145A86224CE4@ex9.hostedexchange.local>
	<ca471dc20612211505wadc09a8jc40f8d2968076799@mail.gmail.com>
Message-ID: <435DF58A933BA74397B42CDEB8145A86224CE6@ex9.hostedexchange.local>

Guido van Rossum wrote:
> Hm, but what would you do with a response not
> in that list that didn't have a content-length?
> You'd have to close the persistent connection.
> We're committed to keep the persistent connection
> open at all times because there's a special
> Googly thing at the other end.

Fair enough. In the case of responses that are required to have no response body, you don't have to close the connection (that's actually a higher-order rule in determining length, see http://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html#sec4.4 point 1). But I can see the benefit to chunking over closing. Thanks for the suggestion.


Robert Brewer
System Architect
Amor Ministries
fumanchu at amor.org

On 12/21/06, Robert Brewer <fumanchu at amor.org> wrote:
>
>
>
> Guido van Rossum wrote:
>  > We decided to add chunking encoding to our own server,
>  > it wasn't all that hard. What's the business of only
>  > doing it for certain status codes?
>
>  Less overhead if the response has no entity or a small one. In my
> experience, 200, 203 and 206 are the only ones that have large enough
> response-bodies to bother. And since there's no spec for a WSGI app to tell
> a WSGI server to chunk (because chunking support isn't mandatory), it seemed
> best for a generic server.
>
>
>  Robert Brewer
>  System Architect
>  Amor Ministries
>  fumanchu at amor.org


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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/web-sig/attachments/20061221/264febdb/attachment.htm 

From ianb at colorstudy.com  Fri Dec 22 05:06:30 2006
From: ianb at colorstudy.com (Ian Bicking)
Date: Thu, 21 Dec 2006 22:06:30 -0600
Subject: [Web-SIG] Paste 1.1.1
Message-ID: <458B59C6.8050305@colorstudy.com>

Paste 1.1.1 is released.

This is a bug fix release, primarily for Windows users.  This fixes a 
bug in the static file serving that would cause all files to give 404 
errors on Windows.

For the full list see: http://pythonpaste.org/news.html

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

From sh at defuze.org  Fri Dec 22 18:48:10 2006
From: sh at defuze.org (Sylvain Hellegouarch)
Date: Fri, 22 Dec 2006 17:48:10 -0000 (GMT)
Subject: [Web-SIG] wsgiref questions
In-Reply-To: <ca471dc20612211303q39e1abbdlcc8443f33534d0ea@mail.gmail.com>
References: <5.1.1.6.0.20061220145018.04c8b838@sparrow.telecommunity.com>
	<5.1.1.6.0.20061220153104.044d1c00@sparrow.telecommunity.com>
	<4589A256.8050302@defuze.org>
	<5.1.1.6.0.20061220172305.0420ff48@sparrow.telecommunity.com>
	<ca471dc20612211303q39e1abbdlcc8443f33534d0ea@mail.gmail.com>
Message-ID: <1322.86.210.57.122.1166809690.squirrel@mail1.webfaction.com>

> We decided to add chunking encoding to our own server, it wasn't all
> that hard.

Hopefully you will release this code as part of wsgiref and let the
community benefit from it, right?

From guido at python.org  Fri Dec 22 18:55:19 2006
From: guido at python.org (Guido van Rossum)
Date: Fri, 22 Dec 2006 09:55:19 -0800
Subject: [Web-SIG] wsgiref questions
In-Reply-To: <1322.86.210.57.122.1166809690.squirrel@mail1.webfaction.com>
References: <5.1.1.6.0.20061220145018.04c8b838@sparrow.telecommunity.com>
	<5.1.1.6.0.20061220153104.044d1c00@sparrow.telecommunity.com>
	<4589A256.8050302@defuze.org>
	<5.1.1.6.0.20061220172305.0420ff48@sparrow.telecommunity.com>
	<ca471dc20612211303q39e1abbdlcc8443f33534d0ea@mail.gmail.com>
	<1322.86.210.57.122.1166809690.squirrel@mail1.webfaction.com>
Message-ID: <ca471dc20612220955j450431c4u79130d70131f0c97@mail.gmail.com>

On 12/22/06, Sylvain Hellegouarch <sh at defuze.org> wrote:
> > We decided to add chunking encoding to our own server, it wasn't all
> > that hard.
>
> Hopefully you will release this code as part of wsgiref and let the
> community benefit from it, right?

We didn't modift wsgiref, we added it to a proprietary module; and I
don't think our code has anything to offer over what's already
available through other channels, such as the CherryPy server.

(Also, wsgiref violates a couple of Python style guides that make me
not want to update it myself. Phillip promised he would clean it up
for distribution but never did, so the version distributed with Python
2.5 has a few strange ideosyncracies that I'm afraid to clean up
because last time someone touched Phillip's code he threw a fit.)

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

From sh at defuze.org  Fri Dec 22 19:01:47 2006
From: sh at defuze.org (Sylvain Hellegouarch)
Date: Fri, 22 Dec 2006 18:01:47 -0000 (GMT)
Subject: [Web-SIG] wsgiref questions
In-Reply-To: <ca471dc20612220955j450431c4u79130d70131f0c97@mail.gmail.com>
References: <5.1.1.6.0.20061220145018.04c8b838@sparrow.telecommunity.com>
	<5.1.1.6.0.20061220153104.044d1c00@sparrow.telecommunity.com>
	<4589A256.8050302@defuze.org>
	<5.1.1.6.0.20061220172305.0420ff48@sparrow.telecommunity.com>
	<ca471dc20612211303q39e1abbdlcc8443f33534d0ea@mail.gmail.com>
	<1322.86.210.57.122.1166809690.squirrel@mail1.webfaction.com>
	<ca471dc20612220955j450431c4u79130d70131f0c97@mail.gmail.com>
Message-ID: <1350.86.210.57.122.1166810507.squirrel@mail1.webfaction.com>

> On 12/22/06, Sylvain Hellegouarch <sh at defuze.org> wrote:
>> > We decided to add chunking encoding to our own server, it wasn't all
>> > that hard.
>>
>> Hopefully you will release this code as part of wsgiref and let the
>> community benefit from it, right?
>
> We didn't modift wsgiref, we added it to a proprietary module;

Makes sense that you can't release it then :)

and I
> don't think our code has anything to offer over what's already
> available through other channels, such as the CherryPy server.

True but the thing is that it's wsgiref which belongs to the stdlib not
CherryPy, it'd be nice if the reference WSGI server could be a little more
complete I suppose. Besides for some obscure reason some people have a bad
opinion of CP.

>
> (Also, wsgiref violates a couple of Python style guides that make me
> not want to update it myself. Phillip promised he would clean it up
> for distribution but never did, so the version distributed with Python
> 2.5 has a few strange ideosyncracies that I'm afraid to clean up
> because last time someone touched Phillip's code he threw a fit.)

Oh good then that I didn't try to understand the Content-Length bug I
raised a few months ago on HEAD requests :)

Thanks for the feedback by the way. Much appreciated.
- Sylvain

From sh at defuze.org  Fri Dec 22 19:15:28 2006
From: sh at defuze.org (Sylvain Hellegouarch)
Date: Fri, 22 Dec 2006 18:15:28 -0000 (GMT)
Subject: [Web-SIG] wsgiref questions
In-Reply-To: <ca471dc20612220955j450431c4u79130d70131f0c97@mail.gmail.com>
References: <5.1.1.6.0.20061220145018.04c8b838@sparrow.telecommunity.com>
	<5.1.1.6.0.20061220153104.044d1c00@sparrow.telecommunity.com>
	<4589A256.8050302@defuze.org>
	<5.1.1.6.0.20061220172305.0420ff48@sparrow.telecommunity.com>
	<ca471dc20612211303q39e1abbdlcc8443f33534d0ea@mail.gmail.com>
	<1322.86.210.57.122.1166809690.squirrel@mail1.webfaction.com>
	<ca471dc20612220955j450431c4u79130d70131f0c97@mail.gmail.com>
Message-ID: <1359.86.210.57.122.1166811328.squirrel@mail1.webfaction.com>

> On 12/22/06, Sylvain Hellegouarch <sh at defuze.org> wrote:
>> > We decided to add chunking encoding to our own server, it wasn't all
>> > that hard.
>>
>> Hopefully you will release this code as part of wsgiref and let the
>> community benefit from it, right?
>
> We didn't modift wsgiref, we added it to a proprietary module; and I
> don't think our code has anything to offer over what's already
> available through other channels, such as the CherryPy server.
>
> (Also, wsgiref violates a couple of Python style guides that make me
> not want to update it myself. Phillip promised he would clean it up
> for distribution but never did, so the version distributed with Python
> 2.5 has a few strange ideosyncracies that I'm afraid to clean up
> because last time someone touched Phillip's code he threw a fit.)
>

One question popped into my mind. One of the core idea behind WSGI is the
pluggability of components respecting the interface proposed by PEP 333. I
wonder if there was reason not to try a different WSGI server when facing
a limitation with wsgiref rather than using a proprietary module? CherryPy
server or another does not matter. Of course since I have no clue of your
infrastructure and design I'm not judging here but your feedback would be
interesting on that particular case. I'm intrigued :)

Thanks,
- Sylvain

From pje at telecommunity.com  Fri Dec 22 19:31:17 2006
From: pje at telecommunity.com (Phillip J. Eby)
Date: Fri, 22 Dec 2006 13:31:17 -0500
Subject: [Web-SIG] wsgiref questions
In-Reply-To: <ca471dc20612220955j450431c4u79130d70131f0c97@mail.gmail.co
 m>
References: <1322.86.210.57.122.1166809690.squirrel@mail1.webfaction.com>
	<5.1.1.6.0.20061220145018.04c8b838@sparrow.telecommunity.com>
	<5.1.1.6.0.20061220153104.044d1c00@sparrow.telecommunity.com>
	<4589A256.8050302@defuze.org>
	<5.1.1.6.0.20061220172305.0420ff48@sparrow.telecommunity.com>
	<ca471dc20612211303q39e1abbdlcc8443f33534d0ea@mail.gmail.com>
	<1322.86.210.57.122.1166809690.squirrel@mail1.webfaction.com>
Message-ID: <5.1.1.6.0.20061222131204.028fa740@sparrow.telecommunity.com>

At 09:55 AM 12/22/2006 -0800, Guido van Rossum wrote:
>(Also, wsgiref violates a couple of Python style guides that make me
>not want to update it myself. Phillip promised he would clean it up
>for distribution but never did,

I only have the vaguest recollection of you mentioning this, but can't find 
any actual emails about it.  As far as I know, I incorporated fixes for all 
of your bug reports, either using your patches or my own.  Would you mind 
refreshing my memory as to the style issues or "ideosyncracies" you are 
referring to?


>  so the version distributed with Python
>2.5 has a few strange ideosyncracies that I'm afraid to clean up
>because last time someone touched Phillip's code he threw a fit.)

If by "fit" you mean the one email I sent to Python-dev requesting that 
others hold off on changes to wsgiref, please note that it was based on:

1. my misunderstanding the policy for changes to externally-distributed 
modules (like wsgiref) and the nature of the purpose of having a designated 
maintainer for contributed stdlib modules,

2. at a time when I was working on incorporating documentation and code 
patches and suggestions from the Web-SIG in order to finish the Python 2.5 
version of wsgiref and release a matching external version for older 
Pythons, all with a tight deadline.  AND, I had just spent a few hours work 
that had to be redone when I discovered that changes (other than the 
automated whitespace normalization) had been taking place on the trunk.

Since I now understand the policy clearly, and am not attempting to 
integrate anything into either version of wsgiref, you are quite safe from 
any emails from me regarding your changes, with the possible exception of 
questions regarding changed functionality.

And even that isn't likely to happen for a while, since I don't foresee 
making any new external releases of wsgiref any time in the next few 
months, barring an emergency due to some horrible bug being discovered.


From guido at python.org  Fri Dec 22 22:26:51 2006
From: guido at python.org (Guido van Rossum)
Date: Fri, 22 Dec 2006 13:26:51 -0800
Subject: [Web-SIG] wsgiref questions
In-Reply-To: <1359.86.210.57.122.1166811328.squirrel@mail1.webfaction.com>
References: <5.1.1.6.0.20061220145018.04c8b838@sparrow.telecommunity.com>
	<5.1.1.6.0.20061220153104.044d1c00@sparrow.telecommunity.com>
	<4589A256.8050302@defuze.org>
	<5.1.1.6.0.20061220172305.0420ff48@sparrow.telecommunity.com>
	<ca471dc20612211303q39e1abbdlcc8443f33534d0ea@mail.gmail.com>
	<1322.86.210.57.122.1166809690.squirrel@mail1.webfaction.com>
	<ca471dc20612220955j450431c4u79130d70131f0c97@mail.gmail.com>
	<1359.86.210.57.122.1166811328.squirrel@mail1.webfaction.com>
Message-ID: <ca471dc20612221326q7eaeb68et9e330e525936da1e@mail.gmail.com>

On 12/22/06, Sylvain Hellegouarch <sh at defuze.org> wrote:
> One question popped into my mind. One of the core idea behind WSGI is the
> pluggability of components respecting the interface proposed by PEP 333. I
> wonder if there was reason not to try a different WSGI server when facing
> a limitation with wsgiref rather than using a proprietary module? CherryPy
> server or another does not matter. Of course since I have no clue of your
> infrastructure and design I'm not judging here but your feedback would be
> interesting on that particular case. I'm intrigued :)

Getting another piece of open source code added to Google's
infrastructure (and learning how to use it) would have been an order
of magnitude more effort than writing the ~50 lines of code that we
ended up adding. One of the downsides of Python's efficiency is that
it's often easier to code than to reuse!

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

From guido at python.org  Fri Dec 22 22:29:01 2006
From: guido at python.org (Guido van Rossum)
Date: Fri, 22 Dec 2006 13:29:01 -0800
Subject: [Web-SIG] wsgiref questions
In-Reply-To: <5.1.1.6.0.20061222131204.028fa740@sparrow.telecommunity.com>
References: <5.1.1.6.0.20061220145018.04c8b838@sparrow.telecommunity.com>
	<5.1.1.6.0.20061220153104.044d1c00@sparrow.telecommunity.com>
	<4589A256.8050302@defuze.org>
	<5.1.1.6.0.20061220172305.0420ff48@sparrow.telecommunity.com>
	<ca471dc20612211303q39e1abbdlcc8443f33534d0ea@mail.gmail.com>
	<1322.86.210.57.122.1166809690.squirrel@mail1.webfaction.com>
	<5.1.1.6.0.20061222131204.028fa740@sparrow.telecommunity.com>
Message-ID: <ca471dc20612221329k656bc33fr29849ad2ba894697@mail.gmail.com>

On 12/22/06, Phillip J. Eby <pje at telecommunity.com> wrote:
> At 09:55 AM 12/22/2006 -0800, Guido van Rossum wrote:
> >(Also, wsgiref violates a couple of Python style guides that make me
> >not want to update it myself. Phillip promised he would clean it up
> >for distribution but never did,
>
> I only have the vaguest recollection of you mentioning this, but can't find
> any actual emails about it.  As far as I know, I incorporated fixes for all
> of your bug reports, either using your patches or my own.  Would you mind
> refreshing my memory as to the style issues or "ideosyncracies" you are
> referring to?

I'll gladly clean it up and send the patch to you for review.

> >  so the version distributed with Python
> >2.5 has a few strange ideosyncracies that I'm afraid to clean up
> >because last time someone touched Phillip's code he threw a fit.)
>
> If by "fit" you mean the one email I sent to Python-dev requesting that
> others hold off on changes to wsgiref, please note that it was based on:
>
> 1. my misunderstanding the policy for changes to externally-distributed
> modules (like wsgiref) and the nature of the purpose of having a designated
> maintainer for contributed stdlib modules,

Yes, misunderstanding are usually the main reason why anybody throws a fit.

> 2. at a time when I was working on incorporating documentation and code
> patches and suggestions from the Web-SIG in order to finish the Python 2.5
> version of wsgiref and release a matching external version for older
> Pythons, all with a tight deadline.  AND, I had just spent a few hours work
> that had to be redone when I discovered that changes (other than the
> automated whitespace normalization) had been taking place on the trunk.
>
> Since I now understand the policy clearly, and am not attempting to
> integrate anything into either version of wsgiref, you are quite safe from
> any emails from me regarding your changes, with the possible exception of
> questions regarding changed functionality.
>
> And even that isn't likely to happen for a while, since I don't foresee
> making any new external releases of wsgiref any time in the next few
> months, barring an emergency due to some horrible bug being discovered.

Great. I may even add HTTP/1.1 and chunked support to it then. (Not
today though, it's family day.)

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

From chad at zetaweb.com  Fri Dec 22 23:04:06 2006
From: chad at zetaweb.com (Chad Whitacre)
Date: Fri, 22 Dec 2006 17:04:06 -0500
Subject: [Web-SIG] wsgiref questions
In-Reply-To: <ca471dc20612221326q7eaeb68et9e330e525936da1e@mail.gmail.com>
References: <5.1.1.6.0.20061220145018.04c8b838@sparrow.telecommunity.com>	<5.1.1.6.0.20061220153104.044d1c00@sparrow.telecommunity.com>	<4589A256.8050302@defuze.org>	<5.1.1.6.0.20061220172305.0420ff48@sparrow.telecommunity.com>	<ca471dc20612211303q39e1abbdlcc8443f33534d0ea@mail.gmail.com>	<1322.86.210.57.122.1166809690.squirrel@mail1.webfaction.com>	<ca471dc20612220955j450431c4u79130d70131f0c97@mail.gmail.com>	<1359.86.210.57.122.1166811328.squirrel@mail1.webfaction.com>
	<ca471dc20612221326q7eaeb68et9e330e525936da1e@mail.gmail.com>
Message-ID: <458C5656.3050804@zetaweb.com>

Guido,

> Getting another piece of open source code added to Google's
> infrastructure (and learning how to use it) would have been an order
> of magnitude more effort than writing the ~50 lines of code that we
> ended up adding.

That's striking. Out of curiosity, can I ask what exactly the 
bureaucracy looks like for open source code to be used at Google? 
Since we're talking WSGI the learning curve is pretty much nil, 
so the bureaucracy must be heavy. Is it mostly a licensing issue? 
Or is it quality assurance?



chad

From guido at python.org  Fri Dec 22 23:11:30 2006
From: guido at python.org (Guido van Rossum)
Date: Fri, 22 Dec 2006 14:11:30 -0800
Subject: [Web-SIG] wsgiref questions
In-Reply-To: <458C5656.3050804@zetaweb.com>
References: <5.1.1.6.0.20061220145018.04c8b838@sparrow.telecommunity.com>
	<5.1.1.6.0.20061220153104.044d1c00@sparrow.telecommunity.com>
	<4589A256.8050302@defuze.org>
	<5.1.1.6.0.20061220172305.0420ff48@sparrow.telecommunity.com>
	<ca471dc20612211303q39e1abbdlcc8443f33534d0ea@mail.gmail.com>
	<1322.86.210.57.122.1166809690.squirrel@mail1.webfaction.com>
	<ca471dc20612220955j450431c4u79130d70131f0c97@mail.gmail.com>
	<1359.86.210.57.122.1166811328.squirrel@mail1.webfaction.com>
	<ca471dc20612221326q7eaeb68et9e330e525936da1e@mail.gmail.com>
	<458C5656.3050804@zetaweb.com>
Message-ID: <ca471dc20612221411pfc92ebfx89b8ca8987718f4d@mail.gmail.com>

On 12/22/06, Chad Whitacre <chad at zetaweb.com> wrote:
> > Getting another piece of open source code added to Google's
> > infrastructure (and learning how to use it) would have been an order
> > of magnitude more effort than writing the ~50 lines of code that we
> > ended up adding.
>
> That's striking. Out of curiosity, can I ask what exactly the
> bureaucracy looks like for open source code to be used at Google?
> Since we're talking WSGI the learning curve is pretty much nil,
> so the bureaucracy must be heavy. Is it mostly a licensing issue?
> Or is it quality assurance?

I think I'm done discussing Google internals.

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

From chad at zetaweb.com  Sat Dec 23 03:13:05 2006
From: chad at zetaweb.com (Chad Whitacre)
Date: Fri, 22 Dec 2006 21:13:05 -0500
Subject: [Web-SIG] wsgiref questions
In-Reply-To: <ca471dc20612221411pfc92ebfx89b8ca8987718f4d@mail.gmail.com>
References: <5.1.1.6.0.20061220145018.04c8b838@sparrow.telecommunity.com>	
	<5.1.1.6.0.20061220153104.044d1c00@sparrow.telecommunity.com>	
	<4589A256.8050302@defuze.org>	
	<5.1.1.6.0.20061220172305.0420ff48@sparrow.telecommunity.com>	
	<ca471dc20612211303q39e1abbdlcc8443f33534d0ea@mail.gmail.com>	
	<1322.86.210.57.122.1166809690.squirrel@mail1.webfaction.com>	
	<ca471dc20612220955j450431c4u79130d70131f0c97@mail.gmail.com>	
	<1359.86.210.57.122.1166811328.squirrel@mail1.webfaction.com>	
	<ca471dc20612221326q7eaeb68et9e330e525936da1e@mail.gmail.com>	
	<458C5656.3050804@zetaweb.com>
	<ca471dc20612221411pfc92ebfx89b8ca8987718f4d@mail.gmail.com>
Message-ID: <458C90B1.7000009@zetaweb.com>

> I think I'm done discussing Google internals.

D'oh!

From rocky at serverzen.com  Sat Dec 23 13:23:09 2006
From: rocky at serverzen.com (Rocky Burt)
Date: Sat, 23 Dec 2006 08:53:09 -0330
Subject: [Web-SIG] wsgiref questions
In-Reply-To: <ca471dc20612221326q7eaeb68et9e330e525936da1e@mail.gmail.com>
References: <5.1.1.6.0.20061220145018.04c8b838@sparrow.telecommunity.com>
	<5.1.1.6.0.20061220153104.044d1c00@sparrow.telecommunity.com>
	<4589A256.8050302@defuze.org>
	<5.1.1.6.0.20061220172305.0420ff48@sparrow.telecommunity.com>
	<ca471dc20612211303q39e1abbdlcc8443f33534d0ea@mail.gmail.com>
	<1322.86.210.57.122.1166809690.squirrel@mail1.webfaction.com>
	<ca471dc20612220955j450431c4u79130d70131f0c97@mail.gmail.com>
	<1359.86.210.57.122.1166811328.squirrel@mail1.webfaction.com>
	<ca471dc20612221326q7eaeb68et9e330e525936da1e@mail.gmail.com>
Message-ID: <1166876587.6637.50.camel@localhost>

On Fri, 2006-22-12 at 13:26 -0800, Guido van Rossum wrote:
> One of the downsides of Python's efficiency is that
> it's often easier to code than to reuse!

I was thinking this very same thing earlier this week.  This can
sometimes be unfortunate.

- Rocky

-- 
Rocky Burt
ServerZen Software -- http://www.serverzen.com
News About The Server (blog) -- http://www.serverzen.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://mail.python.org/pipermail/web-sig/attachments/20061223/06a52b17/attachment.pgp 

From ben at groovie.org  Sat Dec 30 05:52:07 2006
From: ben at groovie.org (Ben Bangert)
Date: Fri, 29 Dec 2006 20:52:07 -0800
Subject: [Web-SIG] ANN: Pylons 0.9.4 Released
Message-ID: <CB8846CB-7191-4E4E-989F-B476FCE01E10@groovie.org>

It's with great pleasure that I announce the release of Pylons 0.9.4.  
This release has quite a few bug fixes and enhancements, the most  
since the 0.9 milestone. It's also likely one of the last big updates  
before a 1.0 release candidate (there will be some small changes in  
0.9.5 and possibly a 0.9.6).

First, the most important changes for those upgrading from an  
existing Pylons application:

* WARNING: Removed the lang_extract and lang_compile commands. They used
   pygettext.py and its associated msgfmt.py, which lacked the  
ability to
   extract ngettext style function calls and had issues with unicode  
strings.
   The new I18NToolBox project aims to provide this functionality  
(and more)
   via the gettext command line utilities. http://i18ntoolbox.ufsoft.org
* WARNING: Myghty's allow_globals config var has changed, causing the
   following when running pre-compiled templates:
       Error(TypeError): do_run_component() takes exactly 13 non-keyword
       arguments (5 given)
   Delete the compiled Myghty templates directory (specified by  
cache_dir or
   myghty_data_dir in the config file) to resolve the error.
* WARNING: The localization function '_' now uses ugettext (returns  
unicode
   strings) instead of gettext. To preserve the old behavior, append the
   following line to your project's lib.base and lib.helpers imports:
   from pylons.helpers import gettext as _
* WARNING: Removed 0.8.x legacy code and backwards compatibility  
functions.

Please note that since some i18n functions have moved, your  
helpers.py will need to be updated to import _, and ungettext from  
pylons.i18n.

Also:

- The XMLRPC Controller got a significant update so that it now  
provides the full range of XML-RPC Introspection facilities for your  
service methods.
- SQLAlchemy convenience functions have been added to pylons.database  
for use with the SessionContext plugin, and to create and retain SA  
engines.
- Paste dependency was updated to 1.1.1, Routes to 1.6.1 (important  
update for map.resource functionality)
- Pylons special objects (g, c, h, request, session) now available in  
interactive debugger without _attach_globals.
- Controller actions can now be generators
- Pylons base WSGI app uses wsgi.org routing_args spec for easier  
swapping of URL resolvers.

== Install ==

Please see http://pylonshq.com/docs/0.9.4/install for installation  
details.

== Full Changelog ==

0.9.4 (Dec. 29th, 2006)
* WARNING: Removed the lang_extract and lang_compile commands. They used
   pygettext.py and its associated msgfmt.py, which lacked the  
ability to
   extract ngettext style function calls and had issues with unicode  
strings.
   The new I18NToolBox project aims to provide this functionality  
(and more)
   via the gettext command line utilities. http://i18ntoolbox.ufsoft.org
* All Pylons special objects are now available within paster shell  
(not just
   h and g).
* WARNING: Myghty's allow_globals config var has changed, causing the
   following when running pre-compiled templates:
       Error(TypeError): do_run_component() takes exactly 13 non-keyword
       arguments (5 given)
   Delete the compiled Myghty templates directory (specified by  
cache_dir or
   myghty_data_dir in the config file) to resolve the error.
* Changed i18n functions in templates to use proxy objects so that using
   set_lang in a template works right. Fixes #153.
* Now allowing any template plugin to overwrite global PYLONS_VARS  
(such as c,
   g), not just pylonsmyghty.
* Adding SQLAlchemy support to the database.py file. Saves the  
session engine
   to g to maintain it during the apps lifetime. Uses SessionContext  
plugin for
   management of the current session.
* Updated config object so that init_app can take an optional  
template engine
   argument to declare the default template engine.
* Updated Myghty plugin to use extra_vars_func when passed in.
* Fixed Buffet to use extra_vars_func properly.
* Fixed the validate decorator when there are validation errors and
   variable_decode=True: now passing the original params to  
htmlfill.render
   instead of the varable_decode'd version. Patch by FlimFlamMan.
* Added ungettext function for use with pluralized i18n, and the N_  
function
   (gettext_noop) to mark global strings for translation. Added  
ungettext, N_
   and translator objects to be globals for templates. Refs #126.
* WARNING: The localization function '_' now uses ugettext (returns  
unicode
   strings) instead of gettext. To preserve the old behavior, append the
   following line to your project's lib.base and lib.helpers imports:
   from pylons.helpers import gettext as _
* Pylons special objects are now available within the interactive  
debugger
   (deprecating _attach_locals).
* Added setup-app run before unit tests run so that webapp has proper  
setup
   tasks handled. Fixes #113.
* Added paste.deploy.CONFIG setup to middleware.py, websetup.py and  
testing
   files in the Pylons project templates. Closes #112.
* Added security policy doc to index for use as Pylons security policy.
   Closes #91.
* Improved the repr() of the c context object to show attributes.
* Set environ['paste.testing_variables'] whenever that key is  
available, not
   just in testing mode.
* Added capability to have an action be a generator function.
* Added introspection capability to XMLRPCController and signature  
checking.
* Updated Controller to use additional arg lookup scheme so that the  
source of
   the function args for _inspect_call can be easily overridden.
* Updated RPCController, renamed to XMLRPCController.  
XMLRPCController now
   functions properly and will automatically return proper xmlrpc  
responses.
* Added test configuration ini file to default template. Closes #114.
* Fixed problem with pylons.database.PackageHub.__get__ raising errors
   other than AttributeError when the database isn't configured.  Added
   new UnconfiguredConnectionError exception, instead of just KeyError
   or TypeError (depending on what part of the configuration failed).
* Fixed default g init, since bare object has no init method.  
Reported by Ian
   Bicking.
* Fixed issue with SQLObject method override having wrong name.  
Reported by
   climbus with patch. Fixes #133.
* Moved log function to pylons.helpers and translation functions to
   pylons.i18n. using pylons.util purely for Pylons internal util  
functions.
* WARNING: Removed 0.8.x legacy code and backwards compatibility  
functions.
* PylonsApp now has option to not use Routes middleware, default  
resolving
   uses new wsgi.org routing_args spec.
* Refactored routes dispatching to use new Routes middleware.
* Fixed paster shell command to properly acquire mapper object without
   relying on the template being configured in a specific manner.
* Added keyword argument pool_connection to
   pylons.database.PackageHub; if set to false then SQLObject  
connections
   won't use pooled database connections (a new connection will be
   opened for each request).

Many thanks to Phil Jenvey, Ian Bicking, James Gardner, and all the  
other active members of the Pylons community!

Cheers,
Ben