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)
>>> 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.
Mark