Erik Faye-Lund

> I'm not convinced on the security concerns. Sure, the security concerns doesn't have to be a problem with all possible implementations. But it does invite scary behavior, which I...

I guess if we saw `GET_TRACK` and `FORGET_TRACK` as something more along the lines of `SUBSCRIBE_TRACK_CHANGES` and `UNSUBSCRIBE_TRACK_CHANGES` mental model, things would make a bit more sense... (edit: unless it's...

Thinking about it, I don't think the ID recycling issue is a real issue in the first place. The IDs are already per connections, they're more like a "subscription ID"...

Sorry for the scatter-brain activity here, but to try to complete the circle: Yeah, I think this could work. I *think* the semantics here would need to be clearer than...

Ugh, you're right. I had forgotten about that intricacy :( Yeah, perhaps `RETIRE_TRACK` + disconnect->reconnect is the right semantics...

I would be surprised if the *real* issue is actually the blocking connect. Sure, you might dip under 60 FPS for that one frame where reconnection happens, but probably not...

Just another thing I just noticed; Windows is the only only "mainstream" platform where we don't set `USE_NODELAY` to disable Nagle's algorithm. Do you think that could be the cause...

> WRT threading, I'm strongly averse to using threads for this. Introducing threads in a little library like librocket just to deal with non-blocking connects is plain gross. Oh, I...

> I actually thought the same thing, but observed the long delay from connect() while testing my changes in WINE here. It only happened in WIN32 and not Linux. During...

I didn't mean to say that I can't be convinced that it's a good idea, but there's some more complications: 1. A lot of people have integrated rocket into their...