Closed tcard closed 6 years ago
While I understand the convenience here I'm against adding this as a supported API and would rather applications implement queueing logic suites there needs for a few reasons:
webSocketDidOpen
really means, it just finished it's handshake and nothing else has taken place yet.PSWebSocket
's are one time use objects.Open to rebuttals on these three points but I'm trying to balance clarity of what the socket does vs developer convenience that is easily implemented at the application level.
To be fair, right now it's probably a bit obscure, you can call send
but depending on your setup it could cause havoc since the behaviour is undefined. As a result once this discussion is finished I'll either implement the queueing logic, or fire an exception if you send messages too soon.
I see your points, and throwing an exception on premature sends is also a good option. It certainly would make a simpler API, at the expense of a bit more of boilerplate on the user's end. So, up to you.
@tcard yea I do get it's a bit of boilerplate for some users, it really comes down to exactly the needs of the application and avoids us trying to match all the queueing needs. I'll add the exception in though so it's clear that you must provide your own queueing logic.
Nothing stopped you from sending a message before the handshake is complete and the websocket is ready. Before this change, doing so could cause a crash if you were unlucky.
I have a codebase that relies on code like this to work:
(I was using SwiftWebSocket before.)
I added a queue of messages sent before the handshake is complete, which makes that safe.