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
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
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