用现在的 bbscon.php 显示附件与用apache直接显示附件相比，有几个缺点：
1. 性能上，肯定apache快且消耗资源少，而且少得多。
2. 功能上，php脚本不支持断点续传，而且对mime-type也不是那么全面。

把附件和文件放在一起我能想到的唯一的好处，就是能够在帖子被删掉的时候
确保附件也被删掉了。不过这只不过是一个取决于程序员细心程度的事情。。。

虽然我觉得把附件和正文分离是一个好主意，但是既然smthbbs或者kbs的代码
不是这样做的，我想一定有什么我没有考虑到的因素。所以想来请教：）

【 在 fancitron (Albatross) 的大作中提到: 】
: 据说smthbbs是从firebird改过来的，而firebird似乎是把帖子的附件文件放在
: 一个专门的目录下的吧，而smthbbs把附件放在帖子正文的同一个文件中，跟在
: 正文后面，是什么原因做这一改变的呢？仿佛觉得原来的方法有更多的好处啊。
: ...................
--
FROM 59.66.199.*

a总ymsw

【 在 atppp (Big Mouse) 的大作中提到: 】
: 性能上提高不了很多，况且apache前端有squid
: php支持Range头毫无难度，不过附件基本都被squid cache，支不支持断点就看squid了
: mime-type不全面是个问题，不过直接用apache的mime判断其实很容易，有空要改下...
: ...................
--
FROM 211.144.200.*

【 在 fancitron (Albatross) 的大作中提到: 】
: 嗯，有cache的话也就无所谓了，不过要是没有cache的话，bbscon.php 里面发送文件
: 是 echo fread(...)，大概需要先把文件读进内存然后再显示出来？@@ 而apache据说
: 有一个效率比较高的sendfile系统调用，对这个调用的细节我不了解，不过据说性能
: 比较好，嘿嘿。
如果你感兴趣可以去看php的代码...理论上php这里读文件可能不用mmap所以也许比apache
直接读要慢一点，不过这点性能差别远远比不上这个操作本身带来的负荷。sendfile
调用肯定也要让内容过内存，这里面的优化基本是os-cpu-dependant...
: 对了，我说的性能是指服务器承受的负担，而不是说显示附件的快慢问题。以上都是
: 推测的。显示附件的快慢从客户端来说当然主要取决于网速，难道我连这都不知道...
: 当然，服务器lag的情形除外。
磁盘i/o和网络i/o，基本就是俩大瓶颈，别的性能问题远比不上这俩...
: 此外，附件和正文分离可以在转载或者收录精华的时候节省磁盘空间。
: 当然，我也就是理论探讨一下，嘿嘿~~~
: 对了，bbscon.php 貌似对web request里的 ap 参数没有合法性检查，随意给定一个
: 参数会导致页面出错(php)，不过这是否有安全隐患我倒没有研究过。
这问题以前提过，安全隐患倒是应该没有，不过是应该检查下...
--
修改:atppp FROM 128.12.181.*
FROM 128.12.181.*

【 在 fancitron (Albatross) 的大作中提到: 】
: 嗯，有cache的话也就无所谓了，不过要是没有cache的话，bbscon.php 里面发送文件
: 是 echo fread(...)，大概需要先把文件读进内存然后再显示出来？@@ 而apache据说
: 有一个效率比较高的sendfile系统调用，对这个调用的细节我不了解，不过据说性能
: 比较好，嘿嘿。

早就知道 sendfile() 了，现在之所以直接用 php 写，就是最开始写的人偷懒而已的。
以前是有过写一个 C 函数放在 phplib 里面的设想，但后来也没动，因为 php 工作
得挺好的，也没见这个东西引起多大的系统负担。

: 对了，我说的性能是指服务器承受的负担，而不是说显示附件的快慢问题。以上都是
: 推测的。显示附件的快慢从客户端来说当然主要取决于网速，难道我连这都不知道...
: 当然，服务器lag的情形除外。
: 此外，附件和正文分离可以在转载或者收录精华的时候节省磁盘空间。
: 当然，我也就是理论探讨一下，嘿嘿~~~

这种情形有过的，不过并不是很好，某站一开始就是这种做法，但后来还是改为
binary 格式文件了，就是被附件没有及时删除烦透了。事实上，如果真的用分离的
办法，就必须有专门的附件清理工具，带来了维护成本。

至于节省空间这个事情，看上去很美，做起来就知道麻烦了。因为这个时候你必须维护
附件的 reference count 了，正文和精华区都指向同一个附件，正文删掉的话，附件还
得留着。当然，在 Unix 里面有一个 link() 可以维护对文件 reference count，但这样
做又有局限性，正文和精华区的文章必须各维护一个附件文件，这个附件文件 hard link
到真正的附件文件。另外一个问题是 hard link 是不能跨文件系统的，这也是局限性。

系统设计是要寻找某种折衷的，可能会有所谓的最优，但不见得这个最优就是最适合的。

: 对了，bbscon.php 貌似对web request里的 ap 参数没有合法性检查，随意给定一个
: 参数会导致页面出错(php)，不过这是否有安全隐患我倒没有研究过。
--
FROM 162.105.242.*

怪不得1.2.2的代码编译不通过呢 -.- 以后就是kbs的天下拉哈哈

【 在 atppp (Big Mouse) 的大作中提到: 】
: 好像只有kbs主分支支持php5,1.2分支好像没加那个支持...
--
FROM 59.66.199.*