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