为 meta 分支的 `plugins.json` API 提供更多信息 about plugincatalogue

[Fallen-Breath]

“提供 更多 信息”这一种，对于插件数据的聚合需求，是无止境的，最后将会成为一个“提供一个文件将整个仓库拉下来分析”的需求。显然，github 已提供了这个接口——https://codeload.github.com/MCDReforged/PluginCatalogue/zip/refs/heads/meta

[AnzhiZhang]

plugins.json 是作为一个 API 提供的，而使用下载量排序也是个很典型的需求，目前可以讨论的是下载量和更新时间的信息，其他信息以及是否会变成无止境应该以后再讨论。这也是API设计中的平衡请求量和请求延迟（单请求信息量），打包整个meta库显然是一种要全部的信息量，一次请求量的做法，相当于把整个后端数据库拉到前端
https://mcdr.waerba.com/ 这个实现就自己重新制作了提供下载量和最后更新时间的API，两大MC模组库也可以展示下载量和更新时间，可见这两个需求是合理且需要的

[Fallen-Breath]

今天想要下载量跟更新时间，明天想要发布版的数量，后天想做 MCDR 适用版本的筛选，下周想做插件依赖关系图……这便是个例子“对于插件数据的聚合需求是无止境的”的例子，若你无法理解

以及，#257 (comment) 是告知，而不是讨论。

[AnzhiZhang]

适用版本是通过requirements筛选的，依赖关系图根本不可能出现在json中
就说更新时间，这是在catalogue分支中显示的，却在plugins中没有
这两点信息不是数据聚合，更不应该以 未来可能产生新的需求 而推断当前的需求不应当实现，应该具体判断
而目前我已经提出关于更新时间的三点考量和关于下载量的两点考量，以及插件库作为插件数据整合处理展示仓库，以上需求数据不应该把整个数据库下载再返工重复处理的一点原因
由于有可能有人PR实现该需求，我暂时不关闭，若你拍板决定不会增加这两项数据也不允许他人实现，烦请直接关闭

[AnzhiZhang]

那么有 PluginMetaSummary 和 AuthorSummary，不提供 ReleaseSummarySummary 和 FormattedPluginInfoSummary 的考量是什么呢？

如果是考虑到文件体积，用这个 https://codeload.github.com/MCDReforged/PluginCatalogue/zip/refs/heads/meta 下载的整个压缩包也只有 200K
将当前插件库的 release 和 info 合并一下，ReleaseSummarySummary 和 FormattedPluginInfoSummary 分别是 335K 和 97K，相对 PluginMetaSummary 的 34K 不是很大

另外这个 https://codeload.github.com/MCDReforged/PluginCatalogue/zip/refs/heads/meta 是不允许跨域的

[AnzhiZhang]

那么有 PluginMetaSummary 和 AuthorSummary，不提供 ReleaseSummarySummary 和 FormattedPluginInfoSummary 的考量是什么呢？

如果是考虑到文件体积，用这个 https://codeload.github.com/MCDReforged/PluginCatalogue/zip/refs/heads/meta 下载的整个压缩包也只有 200K 将当前插件库的 release 和 info 合并一下，ReleaseSummarySummary 和 FormattedPluginInfoSummary 分别是 335K 和 97K，相对 PluginMetaSummary 的 34K 不是很大

另外这个 https://codeload.github.com/MCDReforged/PluginCatalogue/zip/refs/heads/meta 是不允许跨域的

#262 (comment)