Currently, bans are exported to servers via remote ban lists, however, we could export bans to BattleMetrics ban lists that we can provide invites to for other organisations. This will allow server organisations to more easily search bans / keep all their bans in one place.
To ensure that we import bans quickly once they have been issued we should make efficient use of our BattleMetric's API limit and aim to saturate it. This should be achieved with two child process.
The first of these processes should use the same logic as the ban exporter to maintain ban lists but storing the lists as records in the database. Newly created bans should be flagged with a created flag set to false. Delete bans should be flagged with a deleted flag set to false.
The second of these processes should act as a gateway to BattleMetrics looping over the following tasks.
Upload bans from the database that have the created flag set to false to BattleMetrics using the ban import endpoint. The BattleMetric's IDs of the created bans should be stored in the database against the ban's record.
Delete a ban from BattleMetrics that has the deleted flag set to false using the ban delete endpoint. The ban should then be deleted from the database.
Import a ban list page using the logic currently in the ban importer.
Repeating this loop for each available call to the BattleMetrics API will prioritise our rate limit to updating BattleMetrics ban lists and then using any remaining requests to check for new bans to import. Given that the upload/delete tasks rely on new information from the import task, the import task should never become starved of requests.
To cater for people who do not use BattleMetrics the first process could also write to a file that is served as a remote ban list.
Currently, bans are exported to servers via remote ban lists, however, we could export bans to BattleMetrics ban lists that we can provide invites to for other organisations. This will allow server organisations to more easily search bans / keep all their bans in one place.
To ensure that we import bans quickly once they have been issued we should make efficient use of our BattleMetric's API limit and aim to saturate it. This should be achieved with two child process.
The first of these processes should use the same logic as the ban exporter to maintain ban lists but storing the lists as records in the database. Newly created bans should be flagged with a
created
flag set tofalse
. Delete bans should be flagged with adeleted
flag set tofalse
.The second of these processes should act as a gateway to BattleMetrics looping over the following tasks.
created
flag set tofalse
to BattleMetrics using the ban import endpoint. The BattleMetric's IDs of the created bans should be stored in the database against the ban's record.deleted
flag set tofalse
using the ban delete endpoint. The ban should then be deleted from the database.Repeating this loop for each available call to the BattleMetrics API will prioritise our rate limit to updating BattleMetrics ban lists and then using any remaining requests to check for new bans to import. Given that the upload/delete tasks rely on new information from the import task, the import task should never become starved of requests.
To cater for people who do not use BattleMetrics the first process could also write to a file that is served as a remote ban list.