Jerome Louvel wrote:
> It is more efficient to let the HTTP layer pull the content as needed. Let's
> try to not reproduce the same Servlet API design issue again. For background
> info, see: http://blogs.webtide.com/gregw/2004/09/24/1096051860000.html
>
> When we designed the Restlet API, we were extremely careful about this
> aspect. This allows us to have a fully asynchronous processing model on the
> server-side as well as on the client-side. See:
> http://www.restlet.org/about/introduction
>
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?
You'll also have to explain to me why we couldn't just inject NIO
interfaces into the component.
> 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.
> The message body
> writer could perfectly manually close the transaction once the writing is
> done, either by overriding the close() method as suggested by Paul or by
> overriding a new release() method on the MessageBodyWriter interface.
>
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?
This is the real reason I want a streaming API. JAX-RS is a web service
API not necessarily solely a content API. I don't want to have to do
convoluted shit just to be able to do streaming. 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.
Bill
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com