Hi Bill,
> Please no. All that silly syntax sugar just to stream?
It's not silly. It might be that you don't understand our arguments yet.
In your proposal, the outputstream would be written by the request thread
that reaches your resource. Therefore you are stuck with the one thread per
request model *and* you impose this design to all JAX-RS implementations.
Stephan's proposition is different because you don't expose the outputstream
to the request/resource thread. The print(OutputStream) method will instead
be called back by a container's IO/writer thread.
> We're supposed
> to be making it easier for people to develop. The container can
> *easily* proxy OutputStream to bridge any funky internal I/O that is
> going on.
I wish it was that simple. We know how to write proxies, it's easy enough.
Here it is an important design issue.
How would design your HTTP/IO layer to not have one thread per request,
while doing streaming the way you propose? You just *can't*.
> I really don't care if vendor implementations are more
> difficult to write because we want to expose an OutputStream for easy
> streaming.
You missed the point we are trying to make. Just because we gave bad habits
to Servlet developers, letting them directly write to the output stream,
shouldn't force us to carry over this problematic design forever.
Best regards,
Jerome