You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The logout action in its current form rather brutally disconnects the chat client without waiting for pending messages to be delivered. This behavior surprised me. Should it perhaps be more soft, and/or should there be a separate function which waits for the queue to drain before it disconnects?
Proposal A: update the function so it does what I expected. Might break somebody's code where their expectation was different?
Proposal B: simply implement a new function and just mention in the documentation for the legacy function that you probably want the other one. Simple but inelegant.
Proposal C: add a keyword flag and plan a transition where eventually the function will fail if you don't pass in an explicit flag to select which behavior you want. Pesky for multiple reasons when at minimum it will require us to commit to two future upgrades to roll out the new behavior.
Maybe there is a plan D which marries the best of these proposals. Rename the function and start displaying a warning if you use the old name?
The text was updated successfully, but these errors were encountered:
The logout action in its current form rather brutally disconnects the chat client without waiting for pending messages to be delivered. This behavior surprised me. Should it perhaps be more soft, and/or should there be a separate function which waits for the queue to drain before it disconnects?
I have logic implementing this behavior in Sloshy, but I'm not entirely sure how it should be exposed in the library.
Proposal A: update the function so it does what I expected. Might break somebody's code where their expectation was different?
Proposal B: simply implement a new function and just mention in the documentation for the legacy function that you probably want the other one. Simple but inelegant.
Proposal C: add a keyword flag and plan a transition where eventually the function will fail if you don't pass in an explicit flag to select which behavior you want. Pesky for multiple reasons when at minimum it will require us to commit to two future upgrades to roll out the new behavior.
Maybe there is a plan D which marries the best of these proposals. Rename the function and start displaying a warning if you use the old name?
The text was updated successfully, but these errors were encountered: