只是不设置域名的话很难推广及维护。
的确，现在的打算是先放出来验证一下可行性和成本。希望之后还是等官方的国内镜像，学校镜像，华为云或者阿里镜像站来提供服务。把这边验证好之后和其他服务商交涉可能也会比较容易。现在使用的人比较少，带宽还能承受的住，推广开来的话可能带宽也会有压力，也就很难靠一己之力支撑了。
有了Storage Protocol的话，感觉学校的镜像应该可以接受了吧？毕竟可能之前是不支持反向代理类的PkgServer…
- 早期的通过build.jl构造的方式，例如DecFP
这类包如果上游不解决的话， 似乎这只能通过手动修改build.jl解决？
是的。有一些不可控因素会导致这些情况
这样看来还好，之前总担心是因为镜像配置或者网络问题造成的。 之后可能可以加入一些区分机制把这类包带第一次镜像的时候就识别一下生成单独的deprecation list之类，在之后的镜像更新环节跳过。
- 早期的通过build.jl构造的方式，例如DecFP
这类包如果上游不解决的话， 似乎这只能通过手动修改build.jl解决？
这个终归只是一个临时的解决方案，我认为与其在这里考虑如何镜像这类包，不如考虑直接在上游修复…
之后可能可以加入一些区分机制把这类包带第一次镜像的时候就识别一下生成单独的deprecation list之类，在之后的镜像更新环节跳过
前几天在gen_static.jl中他们已经修改了： [gen_static.jl]: Add resource blacklist by staticfloat · Pull Request #40 · JuliaPackaging/PkgServer.jl · GitHub
StorageServer.jl 是从gen_static.jl中重构出来的。后期可能会改造成更纯粹的pkg mirror，即只镜像上游提供的内容。但目前能用就好… 所以对它的加强在我这里的优先级很低…
前几天在
gen_static.jl中他们已经修改了。
感谢告知！
后期可能会改造成更纯粹的pkg mirror
是类似现在USTC Mirror这样的吗？用PkgMirror包支持的并且提供artifacts的？如果这样的话, 仿佛也的确不需要StorageServer，不用考虑给Pkg Server分发…这样可能学校镜像可以提供支持…
StorageServer.jl目前的构建是从General registry和每个包的Artifacts.toml来分析出哪些内容应该被下载和存储下来，如果遇到上游没有或者资源找不到的情况，就会报warning，异常处理什么的挺脏的，比如原始gen_static.jl大概有个七八层嵌套在里面。
一个纯粹的 mirror 协议的话应该是根据上游存储提供的数据来进行下载：上游提供啥就下载啥。这样的话整个代码会变得更简洁更好维护。