GSoC2009 » History » Revision 16
Revision 15 (stbuehler, 2009-03-11 15:22) → Revision 16/23 (fmw, 2009-03-11 15:35)
h1. Google Summer of Code 2009 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 h2. Ideas 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) 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" ** allow multiple files * h264 or Ogg streaming (Ogg Vorbis and Theora codecs are supported natively is the native media codec in Firefox 3.1) ** needs the x-sendfile extensions ** code fastcgi applications to calculate the bytes-offsets for given time-offsets * 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? h3. 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 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.?? -- 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