"""
I disagree with the conclusion that it should, thus, live in each of the N application frameworks out there. From your perspective, it's a feature to do it in some application framework. However, from my perspective, there are some sharp edges to that alternative.
"""
The "secondary pipelines" stuff would likely need to be an "application" (in the WSGI sense of the word) but it would likely be configured to talk to another WSGI 1.0 application on its "right hand side" (eg. it would talk to Pylons, or repoze.zope2, or Grok's WSGI server, or roundup, or whatever). In this sense, it would act like an application proxy. It wouldn't need to be tied to any particular framework. It would have its own configuration stuff. To the "integrator" or sysadmin the WSGI pipeline would end at the "secondarypipelines" application. He would have no way to change the composition of the pipelines defined within it. This is really what I'm after, rather than trying to discourage people from using functional composition to make applications.
"""
I would like to at least see if the itch can be scratched in new ways. If nobody wants it, then it will die of its own accord. If people *do* like the idea though, more than the alternative, then it was a good idea. [wink]
"""
I actually *like* the idea of using functional composition to create applications. I just think WSGI isn't the *right* functional composition.
"""
I guess your proposal is a way to keep the chocolate out of the peanut butter, regarding the flaky WSGI UI ideas?
"""
I wrote an email today where I had to explain my thoughts on it, and I had done it a bunch of times, so I figured I'd write it down so I could just point to it next time. It wasn't due to obsession. ;-)
I disagree with the conclusion that it should, thus, live in each of the N application frameworks out there. From your perspective, it's a feature to do it in some application framework. However, from my perspective, there are some sharp edges to that alternative.
"""
The "secondary pipelines" stuff would likely need to be an "application" (in the WSGI sense of the word) but it would likely be configured to talk to another WSGI 1.0 application on its "right hand side" (eg. it would talk to Pylons, or repoze.zope2, or Grok's WSGI server, or roundup, or whatever). In this sense, it would act like an application proxy. It wouldn't need to be tied to any particular framework. It would have its own configuration stuff. To the "integrator" or sysadmin the WSGI pipeline would end at the "secondarypipelines" application. He would have no way to change the composition of the pipelines defined within it. This is really what I'm after, rather than trying to discourage people from using functional composition to make applications.
"""
I would like to at least see if the itch can be scratched in new ways. If nobody wants it, then it will die of its own accord. If people *do* like the idea though, more than the alternative, then it was a good idea. [wink]
"""
I actually *like* the idea of using functional composition to create applications. I just think WSGI isn't the *right* functional composition.
"""
I guess your proposal is a way to keep the chocolate out of the peanut butter, regarding the flaky WSGI UI ideas?
"""
I wrote an email today where I had to explain my thoughts on it, and I had done it a bunch of times, so I figured I'd write it down so I could just point to it next time. It wasn't due to obsession. ;-)