GSoC2009 » History » Revision 7
Revision 6 (stbuehler, 2009-03-10 19:25) → Revision 7/23 (stbuehler, 2009-03-10 19:54)
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 * implement a scoreboard to cometd?? ??So this needs more specification?? -- stbuehler make server.max-workers a clean approach * improve the lighttpd-angel to integrate nicely with supervise and runit for graceful restarts ** open sockets/log files in the angel * 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 send if you start using multiplexing you loose the filedescriptors via unix-sockets ability to lighty (this probably makes angel unix-only) block data for streaming?? -- stbuehler ** 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?) * h264 or Ogg streaming module (Ogg is the native media codec 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!) h3. For 1.5.0 * streaming upload and chunked encoding for uploads * scalability testing for 1.5.x and its threaded backends on large-scale hardware * continue work on the 1.5 branch to make Windows builds seamless 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 h2. Denied Ideas * scalability testing for 1.5.x and its threaded backends on large-scale hardware ??I don't think "testing" is accepted for GSoC?? -- stbuehler * make mod_fastcgi multiplex requests over same connection, IE exploit CONN_MPX ??I don't think this is -implement 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 mod_wsgi- (see #1523)