(多站点)在线升级功能，预料中就是一个很难的部分，它是一个单独的大功能，已经数不清是几天完成的，这次这个单项功能估计用了6～8个工作日+加班完成。开发中，眼睛需要一刻不停地盯着屏幕几个小时，然后休息一下，因为一中断，就很容易忘记刚才的思路。开始也没有想象它有多么复杂，但是开发、编排中却遇到了不少复杂的逻辑关系，所以开发进度非常慢。其中有一项很纠结的是，多站点更新时，开始设计为当前站点先更新，然后后面的站点再重新排列，这样会遇到很复杂的算法冲突，所以干脆改成了从第1个站点开始依次更新。

如果“多站点更新选项”未做任何设置、或者清空这个选项，则变成单站点升级。

为什么现在一定要把“多站点升级”的功能做出来？因为多站点升级和单站点升级的程序改动非常大，趁我现在还记得程序思路，所以一步到位，一次做好。这个在线升级功能的程序，并非只是Feedval使用，而是Eonval平台下的所有应用都可以通用。

这个多站点更新的程序，我去年已经编写完成，只不过当时写的程序是我个人使用的最简化版(无帐号验证，只有超时验证)。前几天想把以前的程序移植到这次的程序开发中，后来发现一点都不能用，两者的结构有很大的不同，所以只好重新编写，不同之处在于：

去年写的程序，可遍历所有的站点，但是只能自己有新程序更新时，马上现更新，只能更新一期。而现在需要的新功能，是如果用户有好几次没有更新，则必须从那一期没有更新的版本号开始，一次更新为现在的版本。为提高速度、节省双方的资源，将10期的更新合并为一次远程请求；为避免一次下载的数据过多而出现崩溃，我在程序里设定为一次最多下载15个最新的php文件。这里，就会涉及到较为复杂的请求翻页问题，经过大量的测试、调试，还是完成了。

开发中，还需要将所有的错误提示，各种错误情形，能想到的全部都写出来，以避免出错，比如写入失败，则必须出现提示。

程序开发中理想和现实的差距，就是为了实现一个功能，未知的工作量、复杂程度，都是超出预期想象的。

2012年我编写的Arsue Blog当时也有这样的在线功能，但当时的在线功能只能单站点更新，思路现在已经彻底忘记，结构还有些不一样：比如当时的结构是记录了大约有10个左右的字段值，如果用户升级中出现中断、或关闭浏览器，下次升级时能够准确地从上次将要更新的文件接着升级，这次也能实现这一功能，但是因为算法过于复杂，时间有限，所以如果出现关闭浏览器的情况，则下次更新会从上次的更新重新开始。

在线升级程序的开发中，还需要考虑的一个重要、复杂的因素，是如果用户空间某个目录没有写入权限，这时候需要出现错误提示。在线升级程序的内部程序分为2大部分，一部分是某一期运行php文件，对重要数据直接进行修改，这种是修改式更新，这部分的写入失败的错误提示因为是刚刚想到，所以还没有写；另一部分是直接从服务器替换最新的文件，这一种我在编写的软件更新中相对使用最多，这部分的写入失败的错误提示已完成。