(icy, 2009-03-18 19:54)
(icy, 2009-03-24 00:36)
h1. Google Summer of Code 2009
*lighttpd has +not+ been accepted as a GSoC project.*
project. We should have provided more information for students like programming languages required etc. Maybe next year :)
--- 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":http://code.google.com/soc/
h3. 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
List any ideas you have here including a description.
* implement bayeux (cometd protocol) as described in "mod_mailbox":http://blog.lighttpd.net/articles/2006/11/27/comet-meets-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)
* 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":http://h264.code-shop.com/trac)
** 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?)
h3. 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
h3. 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?
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
h2. 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.??
* 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??
* 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??
* 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... :)??