Closed Silverteal closed 6 months ago
基本以 BMCLAPI 为标准吧
其他资源索引按照 BMCLAPI 标准实现的话工作量不是很大吧(
按照第三方镜像可以按照 BMCLAPI 的标准,然后只需修改 apiRoot 即可达成效果
BMCLAPI压力最大的不是索引,是文件,索引才几个字节。 整那么多索引而且又和实际存储分离的话,索引的时效性如何保证?
BMCLAPI压力最大的不是索引,是文件,索引才几个字节。 整那么多索引而且又和实际存储分离的话,索引的时效性如何保证?
索引只是一个概念,用来解释“请求文件后被302到实际地址”这个现象(同时也是302状态码的本义),同时提供一种“分离”的可能性和名义(更好的例子我还没有想出来,先假设比如说:包含某些远古版本的“索引”没有能力提供文件分发服务,从而将请求“索引”到betacraft源,对常规版本则“索引”到官方源),使用“索引”一词受到了一些PyPI的影响,如果对理解有碍,也可以改变。
由于实际文件地址仍然通过索引下发,所以所有的文件仍然可以由索引提供者(镜像源)维护,BMCLAPI不需要作出破坏性改变。
对于启动器方面,目的在于使镜像源成为必要时可替换的,像MCBBS源引入时所做的那样。也正因为很多启动器已经实现了MCBBS源和BMCLAPI源的混合,启动器应该也不需要作很多底层的改动。
此提案对现有情况主要的改变在于上述“可选”部分,如果要引入更多同层级的源,元数据对于识别等用途是必不可少的。不过考虑到在可以预见的未来,应该不会有其它镜像源/索引出现,对于这些改动的要求其实并不紧迫,所以目前列为可选项。
修改 API Root 就好了
本质上,302 的规则也是一种“索引”,而 302 的 Location 则是文件
鉴于本稿件在理解上的歧义,现将其暂时归档。待后续完善或时机成熟后再次提出。
此提案对现有情况主要的改变在于上述“可选”部分,如果要引入更多同层级的源,元数据对于识别等用途是必不可少的。不过考虑到在可以预见的未来,应该不会有其它镜像源/索引出现,对于这些改动的要求其实并不紧迫,所以目前列为可选项。
检查项
您是什么类型的用户
普通用户
请简单的说一下您的想法
基本参照BMCLAPI的现有API,标准化第三方游戏资源索引的实现,并将索引和实际下载源一定程度上解耦。
它能解决什么样的问题/带来什么样的帮助
允许高级用户自定义BMCLAPI/MCBBS/官方以外的其它资源索引,以及为将来现有API的端点(URL前缀,下同)变化作准备
期望的结果
期望中,标准化的索引实现应该:
期望中,标准化实现第三方索引的启动器应该:
是否有对这个方案的相关链接?
No response
附注
基本部分就是照着BMCLAPI描的,并加入了一些可选部分