I'm not sure why I need to repeat myself here
Well I was a bit off topic previously ;)
a) stale data
Yes, but that's not a big deal.
You'll have to do any ways if you wan't to do anything with the client
b) that it's shitty API design if clients need to cache data to be able to use the API
Where's the argument in there?
Because we need to have some foundation that we agree on if we want to actually reason about good vs bad API design
Yes you're right there.
Would you agree that, in an event-based protocol, it's bad API design if you need to resolve to polling to respond to server-side changes?
Highly depends on what you need to poll.
I think especially information which are known have no need of being resend.
This (could) save a ton of bandwidth if applied everywhere.
Anyway, back on point:
The nickname "A", however, is a mutable property. There is no event to notify listeners about changes to that nickname
Does the normal TS3 query system not sending any
clientlistyou could receive the minimum amount of data to properly render the channel tree or a client list (at least what the we're thinking would be the minimum required data).
clientinfoyou're actually able to receive extra data which could be displayed in some kind of "Info" Window or in the TS3 client's case on the right side.
How many commands got lost on the way to the server, and never even got executed? How many got lost on the way back, that is, the commands were executed, but we just couldn't receive the response
Ahh you're more talking of some network issues rather than the server disconnects you.
I see the thing there. But imagine the server side which not only has to keep track of active sessions it would have to track disconnected/inactive as well