On 29/01/2013 00:16, Scott Ferguson wrote:
Fragments are visible to the application. The Javadoc for
Fragments are not visible to the application. The Javadoc should never
refer to fragments.
MessageHandler.Async<T> makes clear that the partial messages are fragments.
I don't see anything in the Javadoc or the specification document thatGetting back to the original question, I still don't see a way ofSince applications don't send fragments, this doesn't make much sense.
sending a fragment larger than Integer.MAX_VALUE through the API except
through a Writer or OutputStream and even then buffering the content (as
the size has to be known before the fragment can be sent) for fragments
larger than Integer.MAX_VALUE is going to be a challenge.
The limits in Session and WebSocketContainer are for incoming messages,
not outgoing messages.
states that the limit only applies to incoming messages. If that was the
intention, it needs to be made clear.
Again, they are.Is it not reasonable to limit fragment sizes supported by this API toAgain, fragments are not visible to this API.
Outgoing doesn't matter. Think about it.
What would be the value of using an int instead of a long? It doesn'tMy point is that there is no way to pass a String, byte or ByteBuffer
save memory or affect performance.
longer than Integer.MAX_VALUE so why even allow the limit to be set
Well, technically true, but a 2^63 long isn't a limit in any practical sense.
It doesn't make sense to put limits on the length of a message because
RFC6455 does not put any limits on message length.
The limit in RFC6455
is on fragment size which is 2^63-1 (Long.MAX_VALUE). While my
preference would be to use the limit from RFC6455 I don't believe it is
practical to do so in a Java implementation. The practical limit is
[jsr356-experts] Re: [jsr356-users] Buffer sizes