以前搞过一个 oneindex 的程序，通过微软的应用接口配合商业版、教育版的 onedrive 网盘，可以把 onedrive 当做一个私人的公开网盘使用。还可以做成一个转链接应用，可以把网盘内容通过转链搞成直链模式，用起来挺好用的。
可以通过 oneindex 可以把自己网盘共享出来，当个自己的个人开放的网盘和图床还是挺好的。
因为没有深入去分析oneindex代码，只是简单在服务器搭建了一个，开始用还可以，但是如果用目录里文件很多，calibre-web目录有十几万个文件，因为 oneindex 会自己索引并缓存目录，十几万个文件夹非常容易把服务器接口搞蹦，还容易触发 onedrive 的 api 接口频率限制，现在考虑可以优化这程序实现，把程序目录给缓存去掉，只实现直链请求在这种大量文件和文件的情况下性能可以优化一些。
但也没想起来要改那些代码，之前只是一心想能直接使用 onedrive 的直链功能，测试了一下 onedrive 自己的文件分享功能，发现请求完分享页面以后，文件目录的下载请求可以通过规律取得，就考虑直接通过 onedrive 自己的分享的下载直链来做图床，理论下官方分享页面不会触发 api 接口和请求频次的限制，也不用考虑改造 oneindex 程序。
通过 onedrive 分享目录直连下载文件，只需要实现一段简单代码，先请求共享目录，再请求具体资源就可以当做图床使用了。
想法挺好，因为之前没有考虑到可以改造 oneindex 的方案，就照着蹭 onedrive 的方向改造了 calibre-web 图书网站，把图书库的那个最大的文件夹共享，当做一个共享目录来使用，通过在网站页面注入一段 js 文件实现了提前加载分享目录，然后再下载图片和图书文件。
通过改造以后实现了图片和文件的下载，后来在做成长社区付费资源站项目的时候，有人提出付费网站需要考虑上传视频的需求，图片用加速cdn还行，但视频用上cdn加速，感觉费用还是太高了，就想自己搞个 WordPress 上传文件到服务器，服务器传文件到 onedrive 的网盘，前台访问通过 onedrive 的分享目录当做直链，可以把 onedrive 当做cdn来使用，播放视频文件也可以在大部分场景下不卡顿了。
这种蹭网盘的思路，以前通过百度网盘的应用共享接口也用过，但当时测试使用网盘第三方应用的接口做直链，请求次数和访问频次呦限制，流量访问高一些就容易被屏蔽请求，很快就导致资源访问失败。
现在再通过改造 onedrive 官方分享接口的方式实现一下，只要 onedrive 分享和下载接口不改动的情况下，应该用起来比自建的应用访问稳定一些。
照着这个思路，又配合服务器安装 rclone 来同步上传的文件，上传文件到 onedrive 的代码都不需要自己写了，只是在wordpress 的主题里把上传文件时写一个调用 rclone 上传文件的钩子（现在想也可以直接用 oneindex 代码 自己写个接口），基本实现了上传到 WordPress 的文件自动同步 onedrive 。网站接口对外请求是用 onedrive 的共享目录的下载接口，图片、视频、附件都可以这样直接下载使用。
实现之前先把思路整理成一个 demo 测试了一下，命名成 oneplayer。原理实现没什么技术含量。主要是验证想法可行性。
经过验证想法可行以后就开始在网站上应用。目前用这种方式的缺陷就是只能通过浏览器来使用，如果用其他程序来播放的话，因为没法携带对应的分享目前访问权限的 cookie，图片不能调用，视频不能支持直链播放，变相实现了资源防盗链的功能。
即便是网页版本，实际上这个 demo 播放起来也是经常有失败现象，实际用起来自己试验项目可以接受，毕竟大部分场景都是成功的。也就没有强求成功率100%了，现在对成功率的要求标准降低了。不想费精力去处理那些小概率事件了，毕竟搞好了也还是不会很稳定使用。
oneplayer demo http://e.bitx.cn/oneplayer/onrplayer-demo.html
写这篇日记的时候，本来是想写写如何用oneplayer 做图床方法的，但前面写着 oneindex 就想到可以通过改造 oneindex 的方式做更稳定一点的直链图床模式，也可以减少对使用图床的网站代码的侵入，那就是把 oneindex 优化一下效率，比一顿魔改 onedrive 分享页面和开发一套 oneplayer 更有效。
所以写完了上半部分日记，就跑去查一次oneindex 的代码有没有可以修改的可能性，一查，发现 oneindex 开发者把代码从 github 上删除了。。
这下找不到源代码了，又从别的服务器和备份中找出来了 oneindex 的源代码，把代码查找出来以后大致看了一下，有可以改造的可能性。搭建了一套新的 oneindex 用来放视频直链，发现不需要魔改播放器就可以很好的满足视频加速的效果。
因为之前一直在搞 onedrive 的分享链接加播放器的 oneplayer，很多视频会出现播放失败的情况，做 demo 时视频播放失败了可以调试，但如果正式上线到生产环境的话，面对大量的视频文件，成千上万的视频发布到网上供人观看的话，就需要通过代码监控视频播放的成功和失败率，用来做针对性的优化，尤其是视频的播放失败日志上报就很重要。
有了日志上报就能很方便的通过日志具体分析视频是因为源文件不存在还是因为网络请求失败导致的不能播放。
这个视频记录日志和出错日志自动上报的程序，我曾经在12年写过一个，当时是为了监控视频网站的播放失败数据，用来排查cdn加速对视频播放质量的影响的。
当时是把程序布到百度的第一个云版本bae环境里面的，后来从bae转移到了京东刚出的云服务器上面，当时是为了做检测用，也顺带想看看这些云服务提供的性能怎么样。但后来京东业务调整有段时间把云业务砍掉了，导致服务器和数据库都被收回了，连代码也没留下，后来自己机器的硬盘也坏了，代码数据全没了。
现在想找出当时写的日志程序再用一下，发现代码都找不到了，当时已经有svn，git等管理工具了。自己也是不断的迁移来迁移去，却还是没保留一个自己的代码库。
现在也不想再写一个单独的程序了，如果只是检测网页的播放失败情况，直接通过百度统计的自定义事件做了一个埋点，大致看看oneplayer视频播放是失败次数就行了，自己做来练手的项目好处就是不需要追求百分百的成功率。
即便统计到了失败率，也很有几率是不会修正，就像以前我统计过的那些视频出错数据一样，当时收集了上万条出错数据，最后也没有优化，只是内部看看了，在整体失败率不高的情况下，不需要继续优化质量了。数据收集也就仅限于数据收集和分析，并没有继续推动开发团队进一步去完善产品的服务质量。
但现在却养成了一个习惯，能做备份的代码，能在公共git服务上做的备份和版本管理的项目，还是要做好版本管理，在开发管理上有帮助，在以后找代码的时候也方便查找。
什么东西做过一次，就不想再重复不断的做了，如果备份没有了，甚至都不想重新写一遍。
oneindex的源代码有人已经备份过，我又在github上克隆了一份：
https://github.com/a1023456/oneindex-1
兜兜转转，很多想法和思路都是在思考，实践和记录的过程中不断完善的，有时候想一次性把事情做好，却在做的过程中不断冒出新的想法和思路。
行动起来，实践中不断学习，才能成长。
或者做着做着发现是个错误的决定，也要及时掉头。