TuRou

> 稍微看了一眼 PR 代码。下次做比较大的变更之前还是先用 RFC 讨论再动手比较好。 > > * 目前开发工作在 `3.2-dev` 以及各个功能分支，其中请求库已经变更为 `httpx` 的协程方式。 > * 希望不要变动顶层 API，具体判断交给类中的功能会比较好 > * 引入的合集解析可以直接集成在 `TitleParser` 中，而非单独拆分出一类，这会让维护变得困难。其他搜索收集功能也是一样的。 > > 感谢 PR，不过还是希望可以按照当下的 Roadmap 和开发进度进行修改，希望下次可以讨论交流之后再着手开发。 感谢review,...

> 与 RSS 解藕如何实现种子信息的解析呢？如果我没理解错实现这项功能需要 AB 内置 BitTorrent 协议吧。 这确实是一个问题, 因为种子文件里面不一定包含目录列表. 不过很多BT站是提供目录列表的, 我们可以不接收种子文件和磁力链接, 只支持从包含目录结构的BT站进行搜索. 看了一下bangumi.moe和爱恋动漫BT都是有文件列表的.

> > > 与 RSS 解藕如何实现种子信息的解析呢？如果我没理解错实现这项功能需要 AB 内置 BitTorrent 协议吧。 > > > > > > 这确实是一个问题, 因为种子文件里面不一定包含目录列表. 不过很多BT站是提供目录列表的, 我们可以不接收种子文件和磁力链接, 只支持从包含目录结构的BT站进行搜索. 看了一下bangumi.moe和爱恋动漫BT都是有文件列表的. > > 那这种方式跟 RSS 获取列表没啥区别吧，上述需求加只要改进解析器让其可以解析合集就可以了吧。 仔细想一下确实是, 我仔细看一下, 然后可能会重开一个RFC

> maybe instead of recalculating pp on a score id going upwards basis calculate it per map? so it goes through all maps in the maps table and recalcs all...

> is this query the problem? > > https://github.com/osuAkatsuki/bancho.py/blob/701c4627cf66c4dd5d5f364ef35e7cd7cb53423a/tools/recalc.py#L183-L190 > > looks like it's only chunked for processing once in memory which is not particularly useful, it should be pulled...

> 感谢您提供的建议，我会好好考虑的。关于后端开发我现在没有明确的方向，您有什么推荐的模块或框架吗？ 后端开发的话用node一般选择比较轻巧的express. 如果有python经验的话, fastapi也是比较不错的选择, 不过引入python的话打包起来比较麻烦和冗余, 不太合理 另外看现在前端主要是jquery, 如果前后端分离了的话可以选择用vue, 会使开发轻巧很多.