by

Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Jun 28 21:07
    Kakifrucht commented #367
  • Jun 28 19:30
    zLvkas opened #367
  • Jun 16 13:47
    yannicklamprecht commented on 68807a9
  • Jun 15 10:45
    qeinz commented on 68807a9
  • Jun 15 08:23
    TheHolyWaffle commented on 68807a9
  • Jun 15 00:07
    qeinz commented on 68807a9
  • Jun 08 12:47
    Emilius123 commented #366
  • May 25 15:12
    PhillTV opened #366
  • May 25 14:26
    pluginyaml opened #365
  • May 15 20:13
    LUF3N closed #364
  • May 15 18:14
    LUF3N commented #364
  • May 15 07:27
    yannicklamprecht commented #364
  • May 15 07:26
    yannicklamprecht commented #364
  • May 14 17:48
    LUF3N opened #364
  • May 14 11:21
    Galileon-venta commented #351
  • May 07 20:10
    DominicFresh closed #359
  • May 07 20:10
    DominicFresh commented #359
  • May 06 13:20
    rogermb commented #359
  • May 06 13:19
    rogermb commented #359
  • May 06 08:30
    DominicFresh commented #359
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
I shouldn't call it transactional, that's a step above what would be required (of course, transactions would be really nice :smile:). What would be required is some kind of journalling
So that if you get disconnected, you could request that the server re-sends the last N responses sent to the client (e.g. the server could limit that to 3 commands)
Then you would have some way to pick back up where you left off, which currently just isn't possible
WolverinDEV
@WolverinDEV
I don't actually see a point in there if the TS3 server fits this requirement (TeaSpeak does):
  • Send a response code for the last processed command
  • Disconnects the client without any further command processing
Roger Baumgartner
@rogermb
Imagine this scenario: you're a client and you send out 5 commands to the TS3 server.
You see from your end that these 5 commands have been sent.
The server starts executing these commands, and you receive 1 command response, but then you get disconnected
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
WolverinDEV
@WolverinDEV

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

I also don't know any other API which does this as well
Roger Baumgartner
@rogermb
Yes, it would have to keep track of the last N command responses for some time, which in my opinion is a manageable overhead, considering that there is only a finite amount of server query accounts on the TS3 server (you obviously wouldn't do that for unauthenticated queries)
But keep in mind that the server query interface is already a stateful protocol; the TS3 server has to keep track of state not only while the TS3 query is online, but also across sessions in the client database
WolverinDEV
@WolverinDEV

Yes I see that point.
It's interesting but I'm actually not seeing a that huge use case tbh.

We could talk back later (started CS match :D)

Roger Baumgartner
@rogermb
Sure! gl & hf!
WolverinDEV
@WolverinDEV
HAHA won :D