Currently, Helma middleware runs within the Helma webapp framework, not at the JSGI connector level. The primary reason was that at the time, I didn't like the way JSGI middleware was composed, e.g.:
f1(f2(f3(f4(f5))))
As it turns out, that's not really a good reason to create our own middleware spec, as the above can be written as:
[f1, f2, f3, f4, f5].reduceRight(function (a, b) {return b(a);})
which in turn could be made to look like this:
wrapMiddleware(f1, f2, f3, f4, f5)
So basically there's no reason Helma can't use and provide true JSGI middleware while allowing apps to define middleware stacks as an array of functions, modules, or module names (using a naming convention for the function name):
implement a top level command for starting web apps (e.g. helma-web)
make the config module export the JSGI app along with the middleware stack and any other configuration properties. This will make sure it is possible to run everything from bare JSGI to full stack apps using the same configuration mechanism. So basically the default JSGI app changes from helma/webapp.handleRequest to config.app.
provide a middleware stacking convention as described in the original report as a convenient alternative to manual composition.
Currently, Helma middleware runs within the Helma webapp framework, not at the JSGI connector level. The primary reason was that at the time, I didn't like the way JSGI middleware was composed, e.g.:
As it turns out, that's not really a good reason to create our own middleware spec, as the above can be written as:
which in turn could be made to look like this:
So basically there's no reason Helma can't use and provide true JSGI middleware while allowing apps to define middleware stacks as an array of functions, modules, or module names (using a naming convention for the function name):