Add idle idleTimeLimit to websocket + eventsource drivers

[devinchristianson]

I'm building a lightweight multi-terminal live streaming project for my own use running labs/demos/etc, and for my use case it was useful to be able to speed through the previously recorded content to get up to the live feed, so I added idleTimeLimit support to the websocket and eventsource drivers.

If this is an improvement that seems worth the effort, feel free to merge this or give feedback so I can get it up to your standard

If this is a niche use case and not worth the time, feel free to close this out

Either way, I'm loving the project, and I appreciate all the hard work!

[ku1ik]

Hey Devin! I'm glad you love the project!

I'm having a hard time understanding the result of this change... maybe because idleTimeLimit as used across this project always meant "remove idle moments by compressing long waits".

Not quite sure how this fits into live streaming, given you can't keep reducing idle time forever: even with a long bufferTime, the buffer will eventually run out if you keep subtracting the delay long enough 🤔

[devinchristianson]

My apologies for the confusion - this change indeed performs the same function, removing idle moments by compressing long waits, it's just the end result is a bit different - if the client joins the stream as soon as it starts, then it indeed has no effect, but if the client joins the stream sometime after it started and the server sends all events from the start of the recording, the idleTimeLimit effectively allows the client to fast forward through the historical recording until it is caught up to the live event stream, at which point it simply displays events as they are streamed.

Perhaps this is a counter-intuitive method of achieving this result, but I thought it fit well into the existing API for drivers and it seems to work well for my purposes at least.