Phillip J Eby rants about people taking code that belongs in an application and trying to turn it into WSGI Middle Ware. Middleware, you see, exists in order to wrap applications with additional behavior. If you can't arbitrarily decide whether to stick it in front of an application, it's not middleware any more. It's part of the application. He also talks about a possible WSGI v2 change to simplify applications and Middle Ware by eliminating the write() callable for unbuffered streaming.

• [Ben Bangert] agrees

Bill De Hora notes - [PJE] describes pointless decoupling via WSGI middleware. No argument from me. In the JaVa world, that a problem is optimally obtained by using [AOP] (Aspect Oriented Programming) for everything. The kinds of things you could could farm out to aspects are much like the ones you can farm out to Middle Ware. Where the variation comes into play is that the set of issues that crosscut an application will vary depending on how you design your application (for example if you use [OO] domain models, threads and logging will crosscut your application), and on the environment (for example if you are building a webapp or a CMS, character encoding will crosscut your application). I gather this sort of thing is why some people see [AOP] as a technique of limited application, rather than a programming paradigm - something along the lines of, you don't design a program with [AOP], you use it to duck and dive around a program.

User Options Recent Changes Help Page