GSoC2009 » History » Revision 22

Revision 21 (icy, 2009-03-18 19:54) → Revision 22/23 (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": 

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

 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) on 
 * 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: 
   -- 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