by

Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Aug 04 11:18
    CheeseTastisch opened #375
  • Aug 04 01:05
    C00ckieHunter edited #374
  • Aug 04 01:04
    C00ckieHunter opened #374
  • Jul 30 23:04
    Mav1st opened #373
  • Jul 30 19:38
    CheeseTastisch closed #372
  • Jul 29 15:32
    rogermb labeled #372
  • Jul 29 15:32
    rogermb commented #372
  • Jul 29 08:25
    TAXSET commented #372
  • Jul 29 07:58
    CheeseTastisch commented #372
  • Jul 29 07:43
    CheeseTastisch commented #372
  • Jul 29 07:42
    TAXSET commented #372
  • Jul 29 07:41
    TAXSET commented #372
  • Jul 29 07:31
    TAXSET commented #372
  • Jul 28 20:12
    CheeseTastisch opened #372
  • Jul 28 20:11
    CheeseTastisch closed #371
  • Jul 23 23:56
    rogermb commented #371
  • Jul 22 21:08
    CheeseTastisch closed #363
  • Jul 22 21:07
    CheeseTastisch opened #371
  • Jul 22 00:08
    rogermb closed #370
  • Jul 22 00:08
    rogermb commented #370
Roger Baumgartner
@rogermb
Because the TS3 server just doesn't send you enough data about the client to be able to do it after the client has already left
NicoGold
@NicoGold
Is there no other way to check something like this?
Roger Baumgartner
@rogermb
Uh, not that I'm aware of. The real problem here is that the client leave event just doesn't send you any identifying information except for the client ID. You'd have to convince the TeamSpeak developers to change that event :stuck_out_tongue:
WolverinDEV
@WolverinDEV
Ît would be stupid to send such data with the leave event.
Since the client is leaving it has been within the clients view earlier.
Therefor you (the viewer) already has such information.
Roger Baumgartner
@rogermb
Yes, but only the server is in possession of a snapshot of the client state at the point in time when the client left the server. And the server doesn't share that snapshot state with anyone. Thus all clients run the risk of using stale information
WolverinDEV
@WolverinDEV
Well you could send a clientinfo command in order to obtain the latest state.
So to build up your own mirror easily. The server only has not really any more information
But yes this would require some work [some criticism] which MC developers sometimes avoid :D
Roger Baumgartner
@rogermb

Well you could send a clientinfo command in order to obtain the latest state.

No, you literally can't. Once the client has left the server, that's it, game over, clientinfo doesn't work anymore.

So to build up your own mirror easily.

Yes, but again, stale data.

The server only has not really any more information

???
No, of course the server has the client's state at the point in time when the client left the server.

Also, this whole argument completely ignores how annoying it is to work with an API that doesn't send you the information you need along with the event. You always necessarily increase the time required to perform actions, and cause more network load and the server's CPU load because clients have to actively ask for information every time

You can't just roll shitty API design onto the developers and say "oh if only they weren't so gosh darn lazy!"
WolverinDEV
@WolverinDEV

Yes, but again, stale data.

Yes the whole post was about that ;)

API that doesn't send you the information you need along with the event

I think you're not pointing on the leave event here, right?

Roger Baumgartner
@rogermb

I think you're not pointing on the leave event here, right?

No, I'm only talking about the leave event. The other events are mostly okay. But the leave event only sends you the client ID, an identifier which becomes worthless by the time the event arrives at the clients

WolverinDEV
@WolverinDEV
Okey, so why the hack would you need more? Since you're already having any information since the join event (imo)
Roger Baumgartner
@rogermb
Yes, again, the problems are a) stale data b) that it's shitty API design if clients need to cache data to be able to use the API. I'm not sure why I need to repeat myself here
WolverinDEV
@WolverinDEV

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?

Roger Baumgartner
@rogermb
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?
Because we need to have some foundation that we agree on if we want to actually reason about good vs bad API design
WolverinDEV
@WolverinDEV

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.

Ofc if this really is required for the leaveevent is questionable.
But if you're taking your focus on minimal network usage, you should apply this everywhere
Roger Baumgartner
@rogermb

I think especially information which are known have no need of being resend.
This (could) save a ton of bandwidth if applied everywhere.

Agree, with some caveats. If it's a common event and we're talking about information that never changes, I completely agree.

So for example, I don't think the protocol would need to send the client's database and unique ID in every textmessage event
But now imagine a really common use-case: If a client leaves the server, I want to print a message saying "Client A has left the server"
WolverinDEV
@WolverinDEV

So for example, I don't think the protocol would need to send the client's database and unique ID in every textmessage event

You're wrong here. Since you could received messages from clients which are not in your view, you actually need such information.

Roger Baumgartner
@rogermb
Ah, alright :smile:
Anyway, back on point:
The nickname "A", however, is a mutable property. There is no event to notify listeners about changes to that nickname
WolverinDEV
@WolverinDEV

But now imagine a really common use-case: If a client leaves the server, I want to print a message saying "Client A has left the server"

Yes, I see that point and thinking of doing so for TeaSpeak (for the query only).

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 notifyclientupdated events?

Roger Baumgartner
@rogermb
nope
So if you have a client that has some kind of a data-freshness requirement - i.e. "I don't want to use a client nickname that is older than 5 minutes", you're out of luck
WolverinDEV
@WolverinDEV
4 real?!
Roger Baumgartner
@rogermb
The only way you can guarantee the freshness of that data would be to send clientlist commands every X minutes
Yup, the server query interface doesn't
I'm not sure if the client query interface does, though, but we're not using that here
WolverinDEV
@WolverinDEV
Well thats a big uff there.
I already knew some drawbacks of the query and actually pusht it a bit.
CQI is some different stuff (kind of)
Roger Baumgartner
@rogermb
And that's just one part where I think the event system is sorely lacking. What also really bothers me is how they can't even use the same identifiers for the same kind of data
WolverinDEV
@WolverinDEV

can't even use the same identifiers for the same kind of data

you're thinking of the cluid and client_unique_id thing right?

Roger Baumgartner
@rogermb
For example, but not only that. The main thing I was thinking about was the data sent in client join events and the responses to clientlist and clientinfo
I'll see if I can find some examples in our code...
Actually, scrap that, they seem to be using the same identifiers there, so no complaints here.
WolverinDEV
@WolverinDEV
HAHA Yes, we're both using the same keys there since the information are stored by thus keys as well
Roger Baumgartner
@rogermb
But another thing that's really quite annoying to work with is how the client join event, clientlist and clientinfo; as well as channelinfo vs channellist send different parts of the available client / channel information that is not a subset of each other
Like, just look at this mess: https://yat.qa/ressourcen/variablen-parameter/ :joy:
Sorry for the German link
WolverinDEV
@WolverinDEV
I'm German all right :D
Yes Redeemer has done some search :D
Roger Baumgartner
@rogermb
But basically, this kind of mess makes designing an object-oriented API around the server query extremely difficult
If you just do a JavaScript, pass around dictionaries of strings to strings and all that, that doesn't really matter, but if you try to actually build a type-safe API, it's extremely annoying
WolverinDEV
@WolverinDEV
But I could actually understand why (I agree it's a mess):
With channellist or clientlist you 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).
With 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.
But more pain the the ass is the thing that responses come without any return code so they're sometimes hard to assign
Roger Baumgartner
@rogermb
Or that the TS3 server offers no way to perform any kind of "transactional" commands. If you get disconnected, you have no clue which commands you sent got executed and which didn't