Hi Mark,
On 2/1/13 3:12 AM, Mark Thomas wrote:
> On 01/02/2013 00:58, Danny Coward wrote:
>> Let me see if I can add a useful summary:-
>>
>> - on frame vs API partial messages
>>
>> We didn't ever intend the API to dictate anything about the underlying
>> frames used to get or send the messages (I think we all agree on that).
>> It looks like the RFC uses 'fragment' to describes messages split across
>> multiple frames. I checked our javadoc uses 'partial messages'. I'm
>> happy to put something clear in a class comment to really stress the
>> developer should not think they are related. OK ?
> The Javadoc does not use "partial message" consistently.
>
> MessageHandler.Async<T> uses "fragment" in some places as does
> RemoteEndpoint.
>
> I think all of those instances of "fragment" need to be changed to
> "partial message".
OK I found 8 in the javadoc and a couple in the spec. They've all been
changed and I have added a note in RemoteEndpoint and MessageHandler
explicitly stating the message parts in the API may or may not have any
relationship with the dataframes.
>> - on buffer sizes
>>
>> I think we originally intended the maximum limits to apply to incoming
>> messages, mainly because some of the developer APIs force buffering
>> (like onMessage(String s)) and the developer needs to say how big an
>> incoming message is too big to wait around for. I think that remains an
>> important control. I agree the javadocs are not clear.
>>
>> The WebSocketContainer holds container scope default maximums, they can
>> be overridden on a per connection basis the corresponding Session instance.
> The session only has a single limit. The container has separate limits
> for Text and Binary. That needs to be consistent.
Thanks for noticing that. Then we should have
get/setMaxBinaryMessageBufferSize() and
get/setMaxTextMessageBufferSize() on session, and these limits are for
incoming only.
>> So does that leave us trying to decide whether to add controls on the
>> buffer size for outgoing messages ? Why would the developer want to
>> limit or control that ?
> If batching is being used I can imagine a circumstance where the
> application would wish to control the size of the outgoing buffer.
Perhaps we can punt on this for this release ?
- Danny
>
> In non-batching mode it is less clear. I suspect folks that are trying
> to fine tune performance may want to be able to modify the size of the
> outgoing buffer.
>
> Mark
>
>> - int/long
>>
>> No-one seems to think that trying to create a buffer bigger than
>> Integer.MAX_VALUE is ever going to make sense, so I am fine turning that
>> into an int.
>>
>> - Danny
--
<http://www.oracle.com> *Danny Coward *
Java EE
Oracle Corporation