On Mar 6, 2008, at 7:17 AM, 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
>
Thanks for the link Jerome, very useful. It occurred to me while
reading it that we are actually quite close to the suggested approach
for resource methods: data is pushed to them in some format they
desire and they return data to be written rather than writing it
themselves - i.e. resource methods are already push/pull. Where we
diverge is in MessageBodyReader/MessageBodyWriter which fall back on
the servlet style pull/push.
I still think its useful to have MessageBodyReader/Writer as a
portable API for applications to add support for new types but
relaxing 3.3.4 a bit would allow implementations to optimize their
support for the required types without compromising that.
Currently 3.3.4 requires implementations to supply MessageBodyReader/
Writer for the listed types but if we relaxed that requirement to
instead simply require an implementation to support those types for
resource method arguments and return types then an implementation
would be free to support them in any desired way including NIO-based
async io.
Marc.
---
Marc Hadley <marc.hadley at sun.com>
CTO Office, Sun Microsystems.