Issues with scaling; inefficient use of client resources

The backend database should not have any problems with handling very large numbers of mailing lists and mails in each list.

However the scripts that interface with the database mostly assume that it is OK to return data from all lists or all mails (at least up to a certain limit). In the case of scripts that are directly accessed by the Javascript GUI, this means that the browser can be presented with very large datasets, requiring a lot of network traffic. This can impact browser memory requirements and potentially broadband data usage. It certainly impacts mobile data usage.

Much of the data that is returned by the scripts is not needed immediately, and may never be used.
Whilst this does reduce lag, it is wasteful of client resources

For example, the initial display only shows domain names, yet the code has used both preferences.lua and pminfo.lua both of which return data about all lists as well as all domains.

Again, once a mailing list is selected, the entire thread structure (with a limit of 15k) for the current period is downloaded by stats.lua, even though only a few mails can be displayed at a time.

Also preferences.lua and pminfo.lua return some overlapping data

Start by reading preferences.lua, pminfo.lua, and stats.lua, then trace how the JavaScript GUI consumes their responses for the initial display and selected-list view. Define done as avoiding unnecessary client data transfer while preserving the data required by those views; the issue names no specific test or command to run.

Written by the indexing model from the issue text.