TODOs
- Improve error handling
- Web-accessible status / information URL
- Test suite or mechanism of some kind
- Test SwitchPipe on more platforms and architectures (OS X and Linux on i386/686 tested so far)
- Improve documentation and Web site
- Stream HTTP message bodies over a certain size to backend apps rather than buffer the whole lot in SwitchPipe (this becomes a necessity when dealing with huge HTTP uploads, say - see Limitations below for more information)
- UNIX socket support for frontend (support already exists for backend)
- Test with nginx / LigHTTPD / other non-Apache HTTP daemons
- Support using the "Host" HTTP/1.1 header for using SwitchPipe directly without a parent HTTP daemon (potentially ideal for API type affairs or even to replace things like nginx entirely and reduce proxying overhead)
- Improve performance
Ideas and Speculative Features
- Caching of some kind
- "keep-alive" support for backends
- Create and support some kind of "packaging" mechanism for Web apps, so users can upload a SINGLE FILE and roll out an app, in a somewhat Goldspike / WAR-esque fashion. Perhaps even using RubyGems (in Ruby's case).
- Direct interaction with "Rack" for Ruby apps
Limitations
Buffering of full requests
No support as yet for "Comet" type long connections / long polling, due to the full buffering of a request before passing it on. Ideally Comet servers should be standalone, so this isn't a significant issue. This issue also means, however, that services that track the progression of file uploads will not work as expected through SwitchPipe either. This is a key issue looking to be addressed in a near future version.