Thanks Scott. I'm going to think on this some more. But just to try to
contrast the two approaches so as to solicit more feedback, in case we
are missing something here:-
The two handlers policy:-
- max two handlers per connection, one for text based messages, one for
binary.
- call policy: ask the text handler to handle text messages, ask the
binary handler to handle binary messages
- unhandled messages: unhandled messages always cause an onError call.
- consequently, a maximum of two @WebSocketMessage annotated methods per
@WebSocketEndpoint class, maximum one with String capable arguments,
maximum one with binary capable arguments
- developer modeling messages with multiple classes does own
multiplexing and downcasting - if (message instanceof Apple) {} else if
{ } etc.
The many handlers policy:-
- many handlers per connection
- call policy: the first handler that can handle the message consumes it.
- same policy of unhandled messages: unhandled messages always cause an
onError call.
- maximum of one @WebSocketMessage annotated methods with the same
message argument type per @WebSocketEndpoint class.
- developer modeling messages with multiple classes has container do the
multiplexing
Other opinions ?
- Danny
On 11/7/12 6:53 PM, Scott Ferguson wrote:
> On 11/7/12 5:58 PM, Danny Coward wrote:
>> Hi Scott, all,
>>
>>>>
>>>
>>> Yes. That's what I was thinking.
>> OK I see. I definitely like the simplicity much better than my
>> original writeup, but it does a little restrictive to limit the
>> developer to one/two handlers.
>>
>> There's a different approach to consider that might be even simpler...
>>
>> - Allow multiple MessageHandlers to be registered in an (ordered)
>> list. When a message comes in, just pick the first MessageHandler in
>> the list that is able to handle the message, and stop.
>>
>> ...yet retain the flexibility to handle different types of messages
>> with different handlers, for those that want to.
>>
>
> I think Justin put it well:
>
>> "I can't imagine too many cases where someone will need multiple
>> encoders/decoders but those people are free to implement an
>> aggregating encoder/decoder and compose their needs into "one."
>
> An application could use a single composite decoder to implement that
> chaining model, if it's appropriate.
>
> But it's not a design that's well-suited to general decoding (for
> example java.io.Serialization):
>
> A better suited model would be:
>
> @WebSocketMessage
> public void onMessage(Message msg) {
> msg.doStuff();
> }
>
> Where the decoder will instantiate/create
>
> class ChatMessage implements Message or
> class LogoutMessage implements Message
>
> as determined by the websocket message. You could use
> java.io.Serialization with the second model, but not the chaining model.
>
> You can see the problem with chaining in the current
> javax.net.websocket.Decoder.BinaryStream, which cannot support the
> chaining model at all. In the case where it could be supported, the
> Decoder.Text, the willDecode(String) is clunky. And that model is
> essentially impossible for encodings like java.io.Serialization.
>
> So the chaining model is pretty specific for a certain kind of
> application. Too specific, I think, to be in this layer.
>> Separately, Scott I logged your suggestion earlier in the thread to
>> move the registration of decoders 'closer' to the MessageHandlers - I
>> agree doing so will make the case of having a
>> MessageHandler.DecodedObject<T> without a Decoder for objects of type
>> T less common.
>
> thanks!
>
> -- Scott
>
>>
>> - Danny
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>>
>>> In practice, I'd expect most sub-protocols would be either text or
>>> binary but not both. (Not enforced, of course.)
>>
>>
>>
>>>
>>> -- Scott
>>>
>>
>>
>> --
>> <http://www.oracle.com> *Danny Coward *
>> Java EE
>> Oracle Corporation
>>
>
--
<http://www.oracle.com> *Danny Coward *
Java EE
Oracle Corporation