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 ?
- 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.
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 ?
- 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
On 1/30/13 1:35 AM, Mark Thomas wrote:
> On 29/01/2013 15:53, Scott Ferguson wrote:
>> On 1/29/13 1:42 AM, Mark Thomas wrote:
>>> On 29/01/2013 00:16, Scott Ferguson wrote:
>>>> Fragments are not visible to the application. The Javadoc should never
>>>> refer to fragments.
>>> Fragments are visible to the application. The Javadoc for
>>> MessageHandler.Async<T> makes clear that the partial messages are
>>> fragments.
>> Those callbacks are not necessarily IETF 6455 fragments.
> Then the JSR 356 specification and Javadoc need to be clarified. If
> RFC6455 talks about messages and fragments and JSR 356 that implements
> RFC 6455 talks about messages and fragments then it is a reasonable
> assumption that they are talking about the same things. If that is not
> that case then the JSR 356 either needs a very, very clear clarification
> or better some different terminology. "Messages" and "partial messages"
> would be fine with me along with some text that made clear "JSR 356
> partial message" != "RFC6455 fragment".
>
>
>>>> The limits in Session and WebSocketContainer are for incoming messages,
>>>> not outgoing messages.
>>> I don't see anything in the Javadoc or the specification document that
>>> states that the limit only applies to incoming messages. If that was the
>>> intention, it needs to be made clear.
>> There's no point of specifying buffer sizes on outgoing messages,
>> because the implementation
>> could choose to use a fixed 256 byte buffer if it wished.
> If outgoing buffer sizes were configurable, the implementation wouldn't
> be able to use a fixed buffer size.
>
> If batching is used then there is likely to be a desire to control the
> outgoing buffer size.
>
> To get back to my original point (which isn't the merits or not of
> controlling the outgoing buffer size) if the specification intends that
> the buffer size only applies to incoming messages then that needs to be
> made clear.
>
>>>>> Is it not reasonable to limit fragment sizes supported by this API to
>>>>> Integer.MAX_VALUE?
>>>> Again, fragments are not visible to this API.
>>> Again, they are.
>> Nope. Protocols like TCP and WebSockets and HTTP don't make their
>> internal fragmentation visible to applications for good reasons.
> I don't disagree with you on that point but my comment about about the
> use of language in the JSR 356 spec stands.
>
>>>> What would be the value of using an int instead of a long? It doesn't
>>>> save memory or affect performance.
>>> My point is that there is no way to pass a String, byte[] or ByteBuffer
>>> longer than Integer.MAX_VALUE so why even allow the limit to be set
>>> above that?
> <snip/>
>
>>> It doesn't make sense to put limits on the length of a message because
>>> RFC6455 does not put any limits on message length.
>> Well, technically true, but a 2^63 long isn't a limit in any practical
>> sense.
> <snip/>
>
>> The limits are for DOS issues.
>>
>> The 2^63 limit was specifically for sendfile. There are files larger
>> than 2G. The current draft doesn't
>> have a sendfile call, but a future one could.
>>
>> long isn't a practical limit because it's not possible to send 2^63 bytes.
> I'm not sure if you are agreeing with me here or not.
>
> If the limits are intended only for incoming messages (which I have no
> issue with but raises the question of how to set a limit for batching
> outgoing messages) and messages are going to be passed to applications
> as byte[], ByteBuffer or String then the limits needs to be set using
> int not long simply because of the maximum size of those objects. There
> is no point allowing a user to set a limit above Integer.MAX_VALUE as
> the implementation will just fall over trying to create a buffer that big.
>
> Mark
--
<http://www.oracle.com> *Danny Coward *
Java EE
Oracle Corporation