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.