项目

通用

个人资料

操作

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

icy近13年前 更新 · 23次修订