Hi Remy,
>>>>> Thanks for the clarification on the real purpose of what you are proposing.
>>>> huh? Why do you always think I'm plotting one thing or another. I'm
>>>> just trying to discuss the pros and cons of various async IO styles.
>>> Yes, I do think that. And I think I have reasons for that.
>> Geeze you are seriously paranoid. No plots here. No secret plans.
>> No hidden agendas. I'm not even sure what option I like best out of
>> a) no async IO; b) traditional canWrite style; c) NIO.2 Style; d) Some
>> new hybrid style. All I know is that we should discuss all the
>> proposals and test them with real examples and analysis.
> What does "no async IO" means ? Is it Servlet 3.0 with no changes ?
>
> About ByteBuffer, a problem here is that mapped byte buffers are seen as
> a general solution, where it's really not the case. Tomcat has a
> specific API for files, so it has uses, but:
> - it doesn't respect or use the Servlet IO (Servlet buffering, char
> output)
> - it's annoying with HTTP transfer encodings (chunking, compression -
> although compression TE has yet to work) or won't work with content
> encoding filters (compression)
Absolutely agree, any kind of content-encoding or SSL may cause
problems, IMO it would make sense to disallow write(ByteBuffer) for such
cases otherwise it would over-complicate the implementation for no benefit.
> Another problem is that the most optimal implementation is application
> dependent. Sometimes it will be copy, sometimes not [and I chose the
> copy method since it fit with the current IO structure, and I believed
> it would be more often optimal]. Of course, there's a big hint if the
> ByteBuffer is array based and not too large.
Agree, IMO for this usecase there is no reason to use write(ByteBuffer)
at all, you can use write(byte[], int, int) instead.
> So probably adding a separate API with ByteBuffer (with support for
> mapped ones in mind) is possible,
Even though write(ByteBuffer) looks a bit alien in ServletOutputStream
API (because of possible limitations, requirements), not sure
introducing separate API is better.
Does it mean we will not be able to use both APIs at the same time?
Would we introduce correspondent API for input?
> but I wouldn't have it replace Rajiv's
> proposal
Agree.
Thanks.
WBR,
Alexey.