Project

General

Profile

GSoC2009 » History » Revision 12

Revision 11 (stbuehler, 2009-03-10 20:30) → Revision 12/23 (stbuehler, 2009-03-10 20:34)

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?? 
   -- 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?) 

 * h264 or Ogg streaming module (Ogg is the native media codec in Firefox 3.1) 
   Need more details: what do you need? pseudo ranged requests via query-string as flash doesn't support them natively? 
   I don't think these ranged requests require a extra module (mod_magnet should be good enough for that; streaming servers should have no problem with that little overhead as they are probably io-bound); and parsing media files in a webserver doesn't look like a sane idea to me. 

 * 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 

 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?? GSoC?? 
   -- 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