Lighttpd

假设¶

随着 Lighttpd 1.5.x 分支的启动，开发过程中存在一些需要解决的不足之处。

作为一款产品，Lighttpd 1.4.x 的质量整体印象因观察角度不同而大相径庭。因此，回顾 Lighttpd

基本设计、特性、性能¶

不可否认，“少即是多”有时确实如此，Lighty 就是其中一例。Jan 奠定的基本设计足够宏大，可以提供相当多的功能，同时又保留了程序整体的“轻量级”感觉。

• 总体：良好。

代码¶

它的构建没有*太多*警告 ;-)。它*有*一个测试框架的事实真是太棒了。

• 这些测试需要维护（或许可以分配/委派给特定的开发人员）。
• 成功执行测试应该成为发布程序的一部分 :-)

文档¶

我们的 Wiki 上有一些最新的教程，这很棒。但是作为参考呢？

• 大部分文档可以从主网页迁移到 Wiki（以便进行联合维护）。

项目组¶

• 总体：除了 Jan 之外，还有哪些人是 SVN 提交者？还有哪些人负责什么？参见 开发者列表

待办事项¶

1.5.x 版本旨在

• 修复阻碍我们前进的内部问题。
• 进行无法在 1.4.x 稳定分支上实现的大改动。
• 合并大部分（如果不是全部）重复代码，这对于代码维护/改进有很大帮助

以下列表供讨论。

• 将 mod_fastcgi、mod_cgi、mod_scgi 和 mod_proxy 合并到 mod_proxy_core 中
  以及围绕它的协议。它们无论如何都是从 mod_fastcgi 剪切粘贴而来的。
  • 核心提供
    • 配置处理
    • 失败时连接/重试
    • 工作子进程死亡时分叉/重启。（更易于改进原生 Win32 支持）
    • 负载均衡
    • x-sendfile
  • 协议后端负责处理
    • 准备环境（大多数 CGI 环境代码可以共享）
    • 编码/解码数据
    • 处理 I/O
• 引入新的 I/O 子系统，允许过滤传入和
  传出数据
  • mod_uploadprogress 可以跟踪上传进度
  • mod_deflate 可以压缩内容
  • mod_multiplex 可以将内容重新路由到其他连接
  • mod_layout 可以在传出流中替换标签
  • 考虑支持异步文件 I/O（很可能使用线程模拟而不是原生 AIO 调用）
• 使核心支持最大工作进程数
  • 整合服务器状态
  • 同步日志文件
  • 也许可以使其基于 Memcached/共享内存/内存映射，以实现集群范围的统计。
• 将大部分配置处理整合到核心中，包括
  • 分配/释放插件数据
  • 初始化默认值
  • 从配置中插入值（到插件数据中）
  • 从插件数据中修补（选择）连接所需的值。
    这是通过调用函数指针来完成的，但我们可以消除字符串比较，这样性能会更低还是更高？
• 将 %n 应用于其他配置选项。
  （例如文档根目录。用户可能会混淆哪些支持或不支持 %n，但似乎很难应用于所有选项。）
• 找到解决模块顺序问题的方法
  • 通过内置的“有序模块列表”对“用户启用的模块”进行排序，但第三方模块无法通过这种方式受益。
  • 或者添加更多“处理阶段”，并依赖“阶段顺序”而非“模块顺序”。这有点过于复杂。
  • 稀疏地为每个模块分配一个数字 ID，并用它来确定加载顺序。
  • 或者……（在此处填写您的解决方案）