On 21/02/2013 23:17, Danny Coward wrote:
> My own take on this is that:
>
> I think it does work :)
> It makes the restriction on the # MessageHandlers harder to explain :(
> It could be useful in some circumstances, but not many :|
>
> What are other folks opinions ?
There would need to be very clear rules on how the Async / Basic
decision is to be taken otherwise different containers will have
different behaviour for the same input and that can't be good.
I suspect that exactly how a message is presented will depend on the
underlying IO implementation used by the WebSocket container. That could
make creating a set of rules on selecting Async / Basic that all
WebSocket implementations could work with tricky.
> Can anyone think of a compelling usecase to justify the increase in
> complexity to explain this ?
No. If folks want to handle the cases differently then they can handle
last == true for the first part of a message as a special case.
> Or should we just wait until the next
> version when we can look at some more formal way to allow multiple
> message handlers.
I think that would be much better.
In short, I see a lot of down sides and no upside at this point.
Mark