小搞不如大搞，要么就不搞

我担心mysql的连接情况，不过它的设置我仍然有点措不着头脑：寻常的修改会令它不能启动,而找不到任何启动不行的错误提示，300改500试过一段时 间，1000改500也试过。（这条要上论坛问一问）,修改是否已经OK？目前只能是以通过show variables看到，是不是就是那个意思？最要命的是启动失败的时侯没有提示。

alexa的计数直线下落，看来它真的经过了一些平滑 的处理。同样有点弄不明白。不过反正可以把它打得挺高的，这就是我的目的。时间上也是有点莫名其妙 的，一会儿一天变几次，一会儿不变，上下变动值也是莫名其妙。section计数也终止了，除非修改基于database的计数，否则不会再得到这个计 数。目前还是先推行为佳。

需要为复基添加维度，以便一个复基服务于多个参照。看来这是有必要的。但进一步就面临着任务扩展的难题了。Database自从几个月前完成以来一直是底层的基础；但也慢慢显得需要合理化操作了。
一来，dababase.xml编辑达到一定数量时，就会显得困难，特别是xml缺乏键管理措施，更加是显得困难；
其次，一次性载入所有记录耗用内存比较大。事实上小基类使用的情况不算很多，完全可以象simplebase一样有读才载入；定时清空；
第三，不能刷新，要等；
第四大类如role很少在运行时访问，没有必要长驻内存，这样就存在着一个希望load和unload设定的要求；
第五把一些基类如role移入其他表还是比较麻烦的，而把artype移入数据库，同样是较大量的工作量；
第六，复基没有经过更严格的运行。

总 之，这不是短时间内可以完成的。牵一发动全身；小搞不如大搞，要么就不搞。看来 这是开发程序中的一个特点，最小化意味着大量合意功能的缺失，小搞意味着大量的重复工作及维护（结构多次移动），成效最低；大搞可以提供全部功能，如果功 能都用得上就是最经济的；如果功能用不上就是不经济的。所以，小搞就变成是最经济的。初步判断这将演变成一个大工程，可能需要一个星期的时间，而且会伴随着抖动。无论是那一条，都是不应该现在进行的理由。

象chase那种问题有时很奇怪的，他不懂技术也无法向他解释：要增加功能就必须有所修改，修改总是有涉及的。如同药总有副作用的，但仍要吃药，就因为病人需要吃药。
会话这个问题到了二级域名真是头痛，完全缺乏重复性。为安全计，还是把与域名相关的部分都在下面引一个iframe为妙。

翻页导引部分一直是虽简单但头痛繁琐的地方，把它合并到一个包含的文件中，更利于提供精细的翻页导引。

下 面正式开始了，在有日志记录的时侯可以清晰地了解到什么事情把工作空间占用了。下午开始的是整理form。hanva.form是另一个大系列的标签， 但应用得比list少，而且也更显得不成熟。用得少的一个重要的原因，以致于一些操作不得不直接写成html，这不符合原来的期望。在form成熟后，大量非常相似的popupform可以归纳为一个文件了。

下面到了注册过程中的修正，但是我完全看不到如何拿到密码的办法。