Nicolo John Davis

Why wouldn't we just use the same mechanism that we use currently to determine the connection status for everyone and not conflate it with onTick? It's quite easy for the...

Yep, what I'm saying is that connection status can be implemented without using onTick.

I think we're talking past each other here. I'm in favor of exploring the onTick mechanism that you're proposing. All I'm saying is that for connect / disconnects, socket.io already...

I understand your concern that it will be difficult to merge certain asynchronous mechanisms with an event driven queue on the server if we eventually go that route (in the...

@lw1990 I'm not sure how #2 is related to this issue. #1 is correct. @TakesTheBiscuit This is not on the radar for v1.

Not at the moment. We only support client side timers right now.

I'm also a bit concerned about the amount of co-ordination required to account to pull this off. There is inevitably going to be some retry logic on the client that...

Yes, that should work. The only downside is that you're depending on an internal implementation detail (for example, if we pull out Redux and use another state management library beneath...

Ah, this is actually deliberate because the AI "framework" (if it is a framework) is still a young experiment and I'm sure that the API will change many times before...

But perhaps having some documentation will help increase adoption which will further help shape the API. So, I'm not fundamentally opposed to having a page about the AI in either...