Thread created on 15:14:37 - 05/08/21 (2 months ago)
Last replied 09:40:49 - 19/08/21 (2 months ago)
I've made the following additions...
[API] Added selections 'newevents' and 'newmessages' which outputs only the events and messages that the player hasn't seen yet [API] Added 'limit' URL parameter to set the number of rows received on 'events' and 'messages' (under 100)
I realised some tools are actually requesting the full most recent 100 events and 100 messages every 30 seconds just to see if any new ones have arrived, because there wasn't really an obvious alternative. If these requests are synchronised across hundreds or thousands of users, the database seems reach some limit and starts writing temporary tables to i/o, which apparently causes a backlog and slows other queries down for everyone. In the long term we'll be moving events and messages off of our servers and on to cloud hosting, like we've done with faction news and the log. I also really want to figure out a way to add socket updates to the API that tools can use instead of this inefficient process.
Ideally, it would be preferable for such tools to utilize the 'from' URL parameter to only check events / messages received since their last call (I.e. from 30 seconds ago), and not pull all 200 every time. But these new calls for 'newevents' and 'newmessages' are at least a good middle ground, this will pull all events/messages that the user hasn't seen yet (by visiting their events / messages page).
Last edited by Chedburn on 17:02:54 - 05/08/21
Are you sure you want to report this post to staff?
It's a nice add-on, but what are the use cases for that? If i want to do a report for specific events, calling that every minute, and reading the new events before my script, I'd lose some of those. I guess it'd be useful only for scripts that would run every 5 seconds or so? The 'from' parameter would probably work better in all the other cases
'limit' accounts for cases where the user wants to be shown a certain number of events, not all of them. Example scenario in Torn PDA would be with the messages and events widgets, where you can see a list of them. Listing 100 is probably too much and difficult to read.
'from' can also be used if you maintain your own database or object in memory after the first call.
And the two new selections makes sense when all we are after are notifications.