Hi Bill,
> You're gonna have to explain to me or link examples on how a
> "content-based" api can do streaming and not have to hold
> large content
> in memory. Is it JAX-RS's MessageBodyReader/Writer model except with
> NIO constructs?
Yes, the MessageBodyReader/Writer model is a good start. In the Restlet API,
we have a Representation class to cover this need:
http://www.restlet.org/documentation/1.1/api/org/restlet/resource/Representa
tion.html
It is not necessary to use the NIO constructs. I think it is way too
low-level for JAX-RS which is supposed to annotate domain beans. BIO streams
are perfectly sufficient for content-based interfaces.
The main point you miss is about the threading-model. I suggest that the
JAX-RS annotated bean returns the working thread immediately after
processing, but without writing any body content itself.
Otherwise, there is no way you can scale beyond one thread per request and
leverage NIO for writing all the responses to the sockets with a limited
pool of writer threads.
> You'll also have to explain to me why we couldn't just inject NIO
> interfaces into the component.
I hope I was clear.
> > I think that the transaction should be left open by the EJB
> container (using
> > the deployment descriptor as explained by Larry I think).
>
> This is a proprietary API.
Maybe this could be standardized by EJB's EG?
> So, instead of a transaction, let's consider what we have to do with
> regular JDBC.
>
> We'd have to write a specific "Content Handler" that handled
> streaming
> the blob and closing/committing the JDBC connection and
> register it with
> the JAX-RS at boot/config time. All just to stream some data?
Can't we already return an inputstream in JAX-RS? So there is no need to
register a custom writer.
> This is the real reason I want a streaming API. JAX-RS is a
> web service
> API not necessarily solely a content API.
No doubt about that, it's all in the name.
> I don't want to have to do
> convoluted shit just to be able to do streaming.
Very poetic and respectful. I'm sure EG members will appreciate.
> What's available to
> the "content API" a.k.a. MessageBodyReader/Writers, should be
> available
> to the component. Sometimes all this abstraction is just
> complete overkill.
My feeling is that JAX-RS is opposite, that the JAX-RS is already too
low-level (hence the feeling that it could replace the Servlet API). By
trying to accommodate 100% of the needs it runs the risk of producing a
suboptimal design.
Best regards,
Jerome