There are at least two layers of security to consider. For the outer firewall (the public interface), a commercially provided socket provides streamlined functionality, despite the occasional glitch already mentioned. But my inner firewalls have no such implementation, leaving "up and over" the only feasible route -- unless I'm in a position to take the firewall down entirely .
this is one case where I do not recommend buffering the output stream. You should check the API, before close() I also recommend a flush(). Strange that every implementation I know rejects them in opposite order.
my mistake, the buffer is on the receiving end, it would be appropriate to flush() there. Normally I'm in favour of programming to an interface and leaving the implementation invisible.. no scratch that, I'm keen to remain in the dark.
That's a rookie move. You've really made me rethink pooling. I always assumed most people were too concerned about integrity to try that.
I didn't mean to imply that I take advantage of the anonymous stream output to a pool -- merely that I've noticed the problem. Luckily, the public-access systems near me with such setups implement a number of filters and anti-virus systems.
Oh yeah... Don't get me started about logging issues in that type of environment. [ December 10, 2007: Message edited by: Ryan McGuire ]
Well put. I agree that keeping the business and the view separate is best.
However, eliminating the roundtrip of calls will land you in serious trouble when you find through your next refactoring a cluster that is very difficult to clean up. Even worse, if you have a bug when going to production, everyone will know it's your fault.
Clearly, doing "the simplest thing that works" isn't always the best practice.
author and iconoclast