Skip to content
TORNLIFE More

Requesting messages & events

Started by Chedburn [1] Admin on in API Development.

4 replies · 255 views · thread synced · 7 days ago · View on torn.com
About this thread

Posts archived: 5 / 5 posts (100%) · the total is Torn's reply count + the opening post at the last fetch

Counted by TornLife from the archived posts.

Archived posts
5
Discussion span
→
People posting
5
Likes on archived posts
15
Posts by staff, officers and moderators
2
Authority score
82 / 100
Historical score
43 / 100
Story score
33 / 100
Engagement score
54 / 100
Chedburn [1] Admin Developer · #1 · edited
Hi everyone,

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

Thanks.
jtower [2287159] · #3 · edited
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
LouBaker [1162207] · #4
I don't know why any script would be reading events every 5 seconds, it would be reading the same info 5 times before any change is found

I don't know how 'limit' parameter will work out as its not known how many events someone has had in the last 30 seconds

using a 'from' parameter would be more efficient as that would be 'from' the last time read
Manuito [2225097] Committee Committee · #5
I think both of them make sense.

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