I thought I'd try to make the Zinc server adaptor use WAComboResponse (like the Comanche adaptor does), but I'm running into some issues.
1. I need a handle on the underlying stream, but this is unknown to the ZnRequest once it's been read. ZnServer knows it, and the entity (if any) knows it if it's been read in a streaming fashion, but otherwise the stream isn't available to the Seaside server adaptor.
2. The Zinc server expects to write a response every time -- it doesn't have the #isCommitted plumbing that Comanche does for checking whether a response has already been committed.
I was first tempted to modify Zinc itself (in blatant violation of the open/closed principle), but perhaps it'd be better to make a new subclass of ZnServer that'd handle these issues natively. The only downside: you'd lose the ability to plug your own ZnServer into your Seaside adaptor. Maybe that's OK, if everybody's basically using the "managing multi-threaded" approach anyway. Do we really need the flexibility of a pluggable threading approach?
Any thoughts/direction would be greatly appreciated.