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
Huh, TIL. Yeah, the description does not seem to be included.
NicoGold
@NicoGold
I used the Channel Topic. That works
BEJUdev
@BEJUdev
How i can is set user discription?
NicoGold
@NicoGold
api.editClient(CLIENTID, Collections.singletonMap(ClientProperty.CLIENT_DESCRIPTION, "DESCRIPTION"));
SopelPL
@SopelPL
Hi. I have a question about getClientsByName() function. This function return only online clients or all (online and offline) clients with given name?
Roger Baumgartner
@rogermb
Only online clients
Client in general is an object that represents an online client. Offline clients are usually represented as DatabaseClient
SopelPL
@SopelPL
How can i change client nickname?
Roger Baumgartner
@rogermb
The query's nickname? setNickname
Other client's nicknames? You can't
NicoGold
@NicoGold
How can I check a client's server group at the ClientLeaveEvent?
Roger Baumgartner
@rogermb
As always with onClientLeave, you need to save the data while the client is still on the server
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.