Google Summer of Code 2009¶

lighttpd has not been accepted as a GSoC project. We don't know the reason yet.

Each year, Google is running their Summer of Code event in which they fund students to work on open source projects.
For more information refer to the official GSoC site

Some hints¶

• lighttpd 1.4.x is our "stable" branch. This means we won't change our core system (no threads for request handling, no "filters")
• lighttpd 1.5.x is the "old" development branch. As we have the sandbox now there are currently no plans to release it, but we think it runs pretty stable (curl -I http://www.lighttpd.net/ :)
  As I don't see who could review bigger core changes they are unlikely to be accepted too (e.g. again no threads for request handling)
• lighttpd sandbox: this is the new development branch. We are still working on the core there, and it is not ready for real-world usage yet; working on this may be a little bit more difficult

Ideas¶

List any ideas you have here including a description.

• implement bayeux (cometd protocol) as described in mod_mailbox
  The concepts looks nice, but i couldn't find docs for how you could connect php to cometd
  So this needs more specification - perhaps we have to create something new here (standard interface for comet applications via fastcgi)
  http://cometdproject.dojotoolkit.org/
  -- stbuehler

• improve the lighttpd-angel to integrate nicely with supervise and runit for graceful restarts
  • open sockets/log files in the angel and send the filedescriptors via unix-sockets to lighty (this probably makes angel unix-only)
  • graceful restart: start new lighty and if it loaded successful have the old one stop accept() and the new one start accept() (+ log file writing/sync?)

• improving the x-sendfile feature
  • support something like open_basedir (e.g. only allow files from /srv)
  • add "x-sendfile-range" (e.g. to enable flexible media streaming as mentioned in the next idea)
  • allow multiple files

• code fastcgi applications to calculate the bytes-offsets for given time-offsets, for codecs like:
  • FLV (replacing the existing mod_flv module)
  • h.264 (replacing the non-free h264 streaming module)
  • Ogg Theora (natively supported in Firefox 3.1)

• implement a mod_webdav variant with a VCS backend (like apache has for svn, but maybe for something nice like git instead)
• alternatively, make a mod_webdav version that is flexible about its backend
• implement a mod_caldav (so lighttpd could become this first pain-free and actually well-working free caldav solution!)

• enhance mod_magnet:
  • add more attract-hooks
  • add more functions to handle the headers/environment/request/response data
  • add interface for async actions (wait for fd?)

For 1.5.0¶

• streaming upload and chunked encoding for uploads
• continue work on the 1.5 branch to make Windows builds seamless
  I am a little bit sceptical on this one. Is this really a worthy GSoC goal ? --stbuehler

For sandbox (aka 2.0)¶

• implement angel process for seamless restarts without losing any connections
• add caching framework
  • check if a cache-module has the content already before producing content e.g. in dirlist/compress
  • probably need a list of active-caches per vrequest
  • how to insert them in the filter queue?

spawn-fcgi¶

Host "next-generation" spawn-fcgi (2.0.x) http://cgit.stbuehler.de/gitosis/spawn-fcgi/ on lighttpd.net:

• add supervise to watch over multiple instances for the same socket

Denied Ideas¶

• implement a mod_wsgi (see #1523 -- stbuehler)
• implement a scoreboard to make server.max-workers a clean approach
  I don't see how the "scoreboard" (list of all connections in mod_status, right?) makes max-workers a clean approach.
  -- stbuehler
• 1.5.0: stop implementing new features and stabilize the branch for a release
  Stabilize is of course a nice idea - but see above for the release plans. I see no reason for a feature stop yet :)
  I think this is not a good GSoC project - too unspecific
  -- stbuehler
• scalability testing for 1.5.x and its threaded backends on large-scale hardware
  I don't think "testing" is accepted for GSoC: http://socghop.appspot.com/document/show/program/google/gsoc2009/faqs#doc_proposals
  -- stbuehler
• make mod_fastcgi multiplex requests over same connection, IE exploit CONN_MPX
  I don't think this is a good idea; keep-alive should be good enough for performance, and if you start using multiplexing you lose the ability to block data for streaming
  The only reason i see is that you would have something to test that feature of a fastcgi application... :)
  -- stbuehler