|Pathologically Eclectic Rubbish Lister|
Re: Net Websocket Serverby roboticus (Chancellor)
|on Aug 01, 2020 at 21:24 UTC||Need Help??|
Normally, when I have a question like that, I'll take a look at the test suite for the module. If you look at the t/01_server.t file in the Net::WebSocket::Server distribution, you'll see that it sets up a server in lines 49 through 106 (for version 0.003004-0) and then tests the utf8 callback in lines 150-157 and the binary callback on lines 159-166:
As you can see, the difference is just what type the client requests. If the client requests type=>'text' it looks like it hits the utf8 endpoint, and you get the binary endpoint when requesting type=>'binary'. I didn't dig into it any further, so I don't know what happens if you don't provide a handler for the type the client requests. I'd expect that it would either complain about an illegal request (e.g., "I don't know how to handle type 'foo'") or let it default to binary and let the binary code either figure it out or complain about an illegal binary request.
Looking at the source code of the module can be helpful, but I frequently find that to be more confusing than looking at the tests: Inside the module, there's a bunch of implementation detail mixed in with the interface, and that can be a bit much to sort through. Looking at the test code, on the other hand, helps you see how to interface with the module without having to trip over the internal implementation details so much. Generally I'll look at the module implementation only if I still have questions after reviewing the test code, and having reviewed the test code, I'll normally have a bit better of an idea of where to look and what to look at.
I hope this helps!
When your only tool is a hammer, all problems look like your thumb.