PyCon and Aspen
Chad Whitacre
I attended PyCon last weekend, and got to meet some of you! :^)
Wanted to follow up here with some thoughts on where Aspen will
be going next.
First, let's knock out these last two issues and release 0.7.1:
Post/redirect problem
http://code.google.com/p/aspen/issues/detail?id=81
PDF content with Aspen/Stephane/Django
http://code.google.com/p/aspen/issues/detail?id=88
These are both proving to be a pain, which means it will be great
to have them fixed. :^)
After that, I'd like to get into the habit of more frequent point
releases, with both fixes and features. We had a fruitful web
deployment BOF at PyCon, and in light of that discussion I would
like to add the following to our 0.7.x roadmap:
Bundled framework support--0.7.1 will include undocumented
support for Django; In 0.7.2, I'd like to add Paste/Pylons
support (Giorgi has shown us how easy that is), as well as
revamped API docs.
Be nice to app sites--currently biased towards publication-
style sites, where the site root contains documents; let's
make it friendlier to app-style sites, where the site root
contains packages (see issue 94).
Robust process monitoring--This emerged as an important
requirement. We already have a restarting implementation, we
need to beef this up to include child daemonization, smart
thrashing, socket saving, etc.
Logging--didn't get much air time at the BOF, except to say
that the stdlib's logging package is the standard: our
problem is really just configuration.
Specialized vs. General--I went in thinking in terms of Aspen
as a specialized server for Python frameworks. However, one
can also read Aspen as a general-purpose web server, with
Python as its extension language. That's a bigger pond!
Thanks to all for your continued interest in Aspen!
chad
iGL
> I attended PyCon last weekend, and got to meet some of you! :^)
> Wanted to follow up here with some thoughts on where Aspen will
> be going next.
Good, but when you blog about, please give a link here ;)
>
> Specialized vs. General--I went in thinking in terms of Aspen
> as a specialized server for Python frameworks. However, one
> can also read Aspen as a general-purpose web server, with
> Python as its extension language. That's a bigger pond!
>
>
Well, I'd suggest to make "aspen suite" rather than one big fat piece
of code. I.e.,
- aspen reverse proxy, balancer, vhoster
- aspen app server - threading (the one we use now)
- aspen app server preforking (maybe - to me threading is enough)
- aspen "static content" server - multiplexing ( here: static content
means anything of non-blocking back-end, like file reads, memcached,
etc)
I do believe such suite is more useful.
So, when you find time, please blog and tell us the latest trends in
Pythonland ;)
greetings,
giorgi
iGL
Chad Whitacre
> Good, but when you blog about, please give a link here ;)
http://tech.whit537.org/2007/02/after-pycon-spring-cleaning.html
:^)
chad
Chad Whitacre
> Oops... sorry, Chad - for I misspelled your name :(
No worries. :^D
chad
asker
Chad Whitacre
Yeah, Bob and I shared a sweet suite. The conversation he
references is being picked up on the Web-SIG, if you're
interested in participating:
http://mail.python.org/mailman/listinfo/web-sig
chad
asker
Where your beard is? :-(
http://www.flickr.com/photos/uhop/400476983/
Did you talk about Aspen to Adrian and James? What do they think?
Regards