[ANN] Aspen 0.7.1

[Chad Whitacre]

All,

I've released Aspen 0.7.1:

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

This gets us caught up on recent issues, and gets us back into
the swing of things as far as releasing goes. The next release
will be more significant. Here are my priorities for 0.7.2:

http://code.google.com/p/aspen/issues/list?q=milestone%3A0.7

Thanks to all for your contributions!

chad

[iGL]

Chad,

> This gets us caught up on recent issues, and gets us back into
> the swing of things as far as releasing goes. The next release
> will be more significant. Here are my priorities for 0.7.2:
>
> http://code.google.com/p/aspen/issues/list?q=milestone%3A0.7
>
>

Looks nice. BTW, shall I add an enhancement ticket?
I would like to have a chance to configure aspen middleware per app,
i.e., to define different sets of wsgi middleware for different apps.
Suppose the scenario: I use pathe '/' for a django app and 'reading'
for a pylons app: then, I certainly have no plans to mix django
middleware set with that of pylons. Or maybe I'm missing something and
its already possible? Is it?

giorgi

[Chad Whitacre]

Giorgi,

> I would like to have a chance to configure aspen middleware per app,
> i.e., to define different sets of wsgi middleware for different apps.
> Suppose the scenario: I use pathe '/' for a django app and 'reading'
> for a pylons app: then, I certainly have no plans to mix django
> middleware set with that of pylons. Or maybe I'm missing something and
> its already possible? Is it?

Well, the idea is to support the most common/simple use cases in
the *.conf files, and to use Python for more advanced cases. So
how about this?

__/etc/apps.conf
/ myapp:root
/reading myapp:reading

__/lib/python2.x/myapp.py

@wrap_with(django_middleware)
def root(environ, start_response):
start_response('200 OK', [])
return ['Greetings, program!']

@wrap_with(pylons_middleware)
def reading(environ, start_response):
start_response('200 OK', [])
return ['Greetings, program!']

Would that address your scenario?

chad

[asker]

Giorgi:
I would like to know if the solution you gave through
http://aspen.googlecode.com/svn/branches/iGL-statres which solves the
speed in reading the content of an static files, or the coupling
between URL static files and the fileSystem static files
representation is, in some way, merged into the new Aspen 0.7.1
Thanks.

[Chad Whitacre]

Vizcayno,

Short story: neither of these changes are in 0.7.1. See below.

> http://aspen.googlecode.com/svn/branches/iGL-statres which
> solves the speed in reading the content of an static files

So that was a performance improvement? I asked and didn't get an
answer:

http://groups.google.com/group/aspen-users/browse_frm/thread/4d8ab135e57d358c/

I thought it was just to fix the open(..., 'rb') problem on
Windows (issue 92), in which case it looked like overkill:

http://code.google.com/p/aspen/issues/detail?id=92

> or the coupling between URL static files and the fileSystem
> static files representation

That involves larger design questions, as Aspen is currently
biased towards publication-style (filesystem-based) sites. I have
a plan for playing nicer with app-style sites, which I'll post
separately.

chad

[gordyt]

Morning Chad,

Just wanted to confirm that issue 88 (PDF generation) seems to be
completely resolved with this build. Thanks very much for all your
hard work!

--gordy

[iGL]

Vizcayno,

asker wrote:
> Giorgi:
> I would like to know if the solution you gave through
> http://aspen.googlecode.com/svn/branches/iGL-statres which solves the
> speed in reading the content of an static files,

I was just about to suggest its removal when I found that done. The
reason was that mongrel users detected instability of the similar
(i.e., chunk-based) static content service API. Even if wsgi
architecture actually removes the problems found in mongrel - such a
handler is really an overkill for aspen core. We all are able to keep
using the chunk-based API through __/lib/python2.4

BTW, if you have time and fun to make benchmarks, comparing,
especially, large file uploads, - please report the results. And if
they appear encouraging, I'd make a special wsgi-based static content
micro-framework with caching and authentication synchronization. You
know, the package by Luke Arno has licensing issues.

> or the coupling
> between URL static files and the fileSystem static files
> representation is, in some way, merged into the new Aspen 0.7.1

I once again vote for it. However, even if Chad decides to keep the
current file-system based architecture, I am going my way and do that
kind of de-coupling again, via __/lib/python2.4. No problem at all,
actually.

> Thanks.
Thank you!
Giorgi

[iGL]

Chad,

>
> __/lib/python2.x/myapp.py
>
> @wrap_with(django_middleware)
> def root(environ, start_response):
> start_response('200 OK', [])
> return ['Greetings, program!']
>
>
> @wrap_with(pylons_middleware)
> def reading(environ, start_response):
> start_response('200 OK', [])
> return ['Greetings, program!']
>
>

> Would that address your scenario?

Thanks - that's at least a good starting point.

giorgi

[asker]

Chad:

> So that was a performance improvement? I asked and didn't get an
> answer:
>

> http://groups.google.com/group/aspen-users/browse_frm/thread/4d8ab135...

>
> I thought it was just to fix the open(..., 'rb') problem on
> Windows (issue 92), in which case it looked like overkill:
>
> http://code.google.com/p/aspen/issues/detail?id=92
>

After I was able to read the static files (.pdf and excel (.xls) )
that are attached to a document archiving system, the process of
getting this files to show on screen lasted too much and usually
application hanged. Giorgi made some adjustments (do not know exactly
what), but after that, the performance was so good. I made some simple
tests and showed the results. Now, I will replace the work made by
Giorgi in his http://aspen.googlecode.com/svn/branches/iGL-statres by
0.7.1 and will dismantle the parameters that he recommended for
middleware.conf, aspen.conf and apps.conf to see how it works in
reading static files.

> > or the coupling between URL static files and the fileSystem
> > static files representation
>
> That involves larger design questions, as Aspen is currently
> biased towards publication-style (filesystem-based) sites. I have
> a plan for playing nicer with app-style sites, which I'll post
> separately.

My best regards.
Vizcayno.