Hi Mark,
On 2/2/13 10:54 AM, Mark Thomas wrote:
> On 02/02/2013 00:24, Danny Coward wrote:
>> 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.
> Sounds good to me.
>
>>>> - 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.
> +1 (please make sure the incoming only limitation is clear in the spec /
> javadoc)
ok, done.
>
>
>>>> 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 ?
> Fine by me. I'd rather the features we do have are unambiguous than add
> new features.
OK then that is what we will do.
- Danny
>
> Mark
>
--
<http://www.oracle.com> *Danny Coward *
Java EE
Oracle Corporation