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
>