Replies: 4 comments
-
It's not counter-intuitive you are just saying it needs to be documented which is true the docs need to be updated with new options https://github.com/uNetworking/uWebSockets/blob/master/misc/READMORE.md#pingpongs-heartbeats https://unetworking.github.io/uWebSockets.js/generated/interfaces/websocketbehavior.html |
Beta Was this translation helpful? Give feedback.
-
Naming can always be better, but that means breaking backwards compatibility. It also means new ways to misunderstand. Docs can also always be better. but so can your testing as well. I mean, even if one would get this wrong - your integration tests should catch it. I read this as a hint that idleTimeout is a bad name - sure I can buy that but it is not a big enough deal to bother introducing a new name. |
Beta Was this translation helpful? Give feedback.
-
Besides, you don't even need to specify idleTimeout - the defaults are configured to automagically manage this for you. So it's like saying "I don't like this green button because I don't know what green means". Well then don't push that green button, or just go read the manual? |
Beta Was this translation helpful? Give feedback.
-
Maybe the best is to simply remove idleTimeout settings from all the examples? |
Beta Was this translation helpful? Give feedback.
-
Auto ping interval being dependent on
idleTimeout
is a bit counter-intuitive.With current defaults,
idleTimeout
might look like it has no effect, because connections will stay open no matter what value you set it to or if there were any messages or not. The fact that chromium based browsers don't display ping frames also doesn't help, but I digress.Generally, having automatic keep-alive mechanism out of the box is pretty great, but IMO naming will make it hard for people to get.
Beta Was this translation helpful? Give feedback.
All reactions