Feature summary (what you would like to be able to do and where):
DPL was originally released in 2005 for Wikinews, forked several times, and then DPL3 is used a lot on Fandom and Miraheze but it has the downside of being very resource intensive. DPL3 is used on Fandom wikis such as Genshin Impact Wiki in order to fetch and format various lists from various categories. DPL3 was recently superseded by DPL4, but neither are compatible with MediaWiki 1.45+ (yet), nor are they suited for Wikimedia.
This task is about developing a successor to DPL that solves almost all of the performance issues with long queries and load times, even with caching of the results.
Much of the functionality would remain the same as DPL3/DPL4, just under the hood there would be some things that were different. For example, on page save when a query with specific parameters is run the first time, a query should be able to run asynchronously, with an error message shown to the reader that the query is not ready yet (and a link to purge the page). There would not be more than a few DPL queries running at a time to prevent performance issues, so some queries might take hours or days to update depending on properties such as the size of the category, whatlinkshere, etc. where the query is being run.
There should also be a Lua function mw.ext.DPL(...) that would throw a Lua error similar to what is seen above when the query has not finished; as well as a JS function mw.ext.DPL(...) that runs asynchronously (and returns a Promise object) to fetch a DPL query using an API (maybe a REST API such as /api/DPL?[properties] or the action API /api.php?action=dpl&dplqueryparams=[properties]), and if the API does not return a result within a minute it rejects the promise and throws a similar error. This MW API could be rate limited to a specific number of queries per user per day, with higher rate limits for logged in users and even higher ones for bot and administrator accounts.
Each DPL invocation from anywhere other than the APIs would increment the expensive parser function count. There would also be a DPL sandbox that allows people to experiment with and generate DPL queries.
The extension should be backwards compatible with DPL (WMF) and DPL4.
Use case(s) (list the steps that you performed to discover that problem, and describe the actual underlying problem which you want to solve. Do not describe only a solution):
Much of the use cases would be on list articles on Wikipedia. For example, one can have a list article on Wikipedia such as "List of K-pop groups" and have a DPL query that fetches all of the groups and presents them in a list.
Another use case would be to allow for the review of speedy deletions by administrators as they can preview the reason why the page has been nominated for speedy deletion.
Benefits (why should this be implemented?):
This would save editor time by allowing pages to be dynamically updated in near-real time. The original implementation of DPL has had problems that prevented DPL from being expanded to other wikis. If this extension was reworked from the ground up addressing much of the performance concerns, it could potentially be used on more Wikimedia projects with little performance concerns.