Hi Bill,
> To take *full* advantage of Non-blocking I/O application code
> needs to be aware of and do chunking (although there could be
> a framework to help with this). I think a better link at what
> your response model solves is talked about here:
> http://docs.codehaus.org/display/JETTY/Continuations
In all cases where the resource/representation generation code doesn't
block, it is possible to let the HTTP writer threads pull the data as
needed, byte after byte. In this case, you can break the thread per request
barrier.
> Really the AJAX polling problem. Unless your JAX-RS service
> falls into this particular usecase, your response model isn't
> really going to solve many performance issues.
I don't this we should include AJAX/Continuation use cases in JAX-RS. It is
not a fully standard practice (regarding REST/HTTP) and is way too low-level
for JAX-RS. This is better left of to Servlet 3.0 EG/Jetty
Continuations/DWR.
> Beyond the BLOB case I talked about before, if you look at servlet
> development, people use the raw output stream or print
> writers to stream
> dynamic content. Developers will *still* want to use a raw output
> stream especially if they are migrating an existing Servlet-based
> restful service to the JAX-RS model.
Replacement of Servlet API by JAX-RS has never been a goal (implicit or
explicit) of this specification. Maybe we need a clarification from the spec
leaders?
> We should not enforce either the Representation or MessageBodyWriter
> architecture on simple applications that just want to stream dynamic
> data because of one particular AJAXian (mis)usecase.
I agree, that why we can just return an InputStream that will provide the
dynamic content to the HTTP writer thread as needed.
> That being said, I like your Representation object and allowing the
> Resource class the ability to create and pass back this object rather
> than having to write and register a MessageBodyWriter
> separately. So +1 on that.
Thanks for this comment. Note that we are implementing JAX-RS on top of the
Restlet API and that we see both API complimentary. JAX-RS is
annotation-driven while Restlet API is class-driven. See this post for
details:
http://blog.noelios.com/2007/04/25/restlet-api-and-jsr-311-api/
> Still, I do think that most JAX-RS application developers will find
> getting access to the Input and OutputStreams very useful. I know I
> have already found the need for this in the first two
> applications I've prototyped with JAX-RS.
Support for InputStreams is easy and already in. Support for OutputStream is
not so hard and already in as well. I vote to status quo.
> I don't think getting access to Input/OutputStreams creates a
> suboptimal design. Since a JAX-RS endpoint uses annotations rather
> than a static interface contract to process requests, its easy to
> plug in new models as they become available through the specification
> or as vendor plugins. The key is to get the extension SPIs correct.
Again, returning an InputStream is fine and optimal. My issue is with giving
a direct access to Response's OutputStream is that it forces
thread-per-request model and prevents optimization in the HTTP/IO layers.
Best regards,
Jerome