操作
2009年Google编程之夏¶
lighttpd 未 被选为GSoC项目。
我们本应为学生提供更多信息,例如所需的编程语言等。也许明年吧 :)
每年,Google都会举办编程之夏活动,资助学生从事开源项目。
更多信息请参考GSoC官方网站
一些提示¶
- lighttpd 1.4.x 是我们的“稳定”分支。这意味着我们不会改变我们的核心系统(请求处理无线程,无“过滤器”)
- lighttpd 1.5.x 是“旧”开发分支。由于我们现在有了沙盒,目前没有发布计划,但我们认为它运行得相当稳定(curl -I https://lighttpd.ac.cn/ :))
由于我不知道谁能审查更大的核心改动,因此它们也不太可能被接受(例如,再次没有用于请求处理的线程) - lighttpd 沙盒:这是新的开发分支。我们仍在开发核心,尚未准备好用于实际应用;在此基础上工作可能会更困难一些
想法¶
在此列出您的任何想法,包括描述。
- 实现bayuax(cometd协议),如mod_mailbox中所述
这个概念看起来不错,但我找不到如何将 PHP 连接到 cometd 的文档
所以这需要更多规范——也许我们必须在这里创造一些新的东西(通过 FastCGI 实现 comet 应用程序的标准接口)
http://cometdproject.dojotoolkit.org/
-- stbuehler
- 改进 lighttpd-angel,使其与 supervise 和 runit 良好集成,实现平滑重启
- 在angel中打开socket/日志文件,并通过unix-socket将文件描述符发送到lighty(这可能使angel仅限于unix)
- 平滑重启:启动新的lighty,如果加载成功,则让旧的停止accept(),新的开始accept()(+日志文件写入/同步?)
- 改进 x-sendfile 功能
- 支持类似 open_basedir 的功能(例如,仅允许来自 /srv 的文件)
- 添加“x-sendfile-range”(例如,实现下一个想法中提到的灵活媒体流)
- 允许多个文件
- 编写 FastCGI 应用程序来计算给定时间偏移的字节偏移量,适用于以下编解码器:
- FLV(替换现有的 mod_flv 模块)
- h.264(替换非自由的h264 流媒体模块)
- Ogg Theora(Firefox 3.1原生支持)
- 实现一个带有 VCS 后端的 mod_webdav 变体(类似 Apache 用于 svn 的,但也许用于像 git 这样不错的)
- 或者,制作一个对后端灵活的 mod_webdav 版本
- 实现一个 mod_caldav(这样 lighttpd 就可以成为第一个无痛且实际运行良好的免费 caldav 解决方案!)
- 增强 mod_magnet
- 增加更多吸引钩子
- 添加更多函数来处理头/环境/请求/响应数据
- 添加异步操作接口(等待fd?)
针对 1.5.0¶
- 流式上传和分块编码上传
- 继续在 1.5 分支上工作,使 Windows 构建无缝衔接
对此我有点怀疑。这真的值得作为 GSoC 目标吗? --stbuehler
对于沙盒(即 2.0)¶
- 实现 angel 进程以实现无缝重启而不会丢失任何连接
- 添加缓存框架
- 在生成内容之前检查缓存模块是否已包含内容,例如在 dirlist/compress 中
- 可能需要一个vrequest的活动缓存列表
- 如何将它们插入过滤器队列?
spawn-fcgi¶
在 lighttpd.net 上托管“下一代”spawn-fcgi (2.0.x) http://cgit.stbuehler.de/gitosis/spawn-fcgi/- 添加 supervise 来监视同一套接字的多个实例
被拒绝的想法¶
- 实现 mod_wsgi(请参阅 #1523 -- stbuehler)
- 实现一个记分板,使 server.max-workers 成为一种清晰的方法
我不明白“记分板”(mod_status 中的所有连接列表,对吧?)如何使 max-workers 成为一种清晰的方法。
-- stbuehler - 1.5.0:停止实现新功能,稳定分支以发布
稳定当然是个好主意——但请参阅上面的发布计划。我目前看不到停止功能的理由:)
我认为这不是一个好的 GSoC 项目——太不具体了
-- stbuehler - 在大型硬件上对 1.5.x 及其线程后端进行可伸缩性测试
我认为“测试”不被 GSoC 接受:http://socghop.appspot.com/document/show/program/google/gsoc2009/faqs#doc_proposals
-- stbuehler - 使 mod_fastcgi 通过同一连接复用请求,即利用 CONN_MPX
我认为这不是一个好主意;keep-alive 对于性能来说应该足够了,如果你开始使用多路复用,你会失去阻塞数据进行流传输的能力
我看到的唯一原因是你会有一些东西来测试 FastCGI 应用程序的那个特性…… :)
-- stbuehler