> Inline responses:
> On Tue, Jul 3, 2012 at 4:03 AM, Greg Wilkins <[hidden email]> wrote:
> Jesse and I have been favoring a more simple approach.
> onWebSocketMessage(Message message)
> Message object
> boolean isComplete() - indicates if the complete String or binary blob
> is contained in the message
> boolean isText() - special check for content sent as Op=TEXT with
> assumption that the content will be UTF8 compliant
> // Message Data APIs
> String getText() - returns the complete text of the message
> ByteBuffer getBytes() - returns the complete binary blob of the message
> // Streaming APIs
> Reader getReader() - returns a reader for streaming a text message
> InputStream getStream() - returns a reader for streaming a binary
> ReadableByteChannel getChannel() - returns a channel for reading for
> streaming back the message
I don't like isText(). I think this is a case for polymorphism and
have a TextMessage and a BinaryMessage return type. Also why not have
and then we have an asynchronous API. I will suggest this to the
JSR356 and see what they say.
> All writes are non-blocking (or at least they should be IMO)
The writes with callbacks should be non-blocking, but I'm not so sure
about the writes without callbacks.
The problem with those is it makes the memory management really
difficult, if we have
that is blocking, then it is unclear when or if those buffers can be
reused or returned to a pool etc. If this method is blocking, then
the memory management is clear: when the method returns those buffers
are free to be reused etc.
Essentially the no-call back methods are just convenience methods as
it is pretty trivial to use a callback to make a blocking send - but
it takes 3 lines.