Project

General

Profile

DevelopmentProceduresR1 5 » History » Revision 10

Revision 9 (Anonymous, 2006-05-11 05:43) → Revision 10/15 (moo, 2006-05-30 04:54)

== Assumptions == 
 As the Lighttpd 1.5.x branch is starting, there are a couple of deficiencies in the development process that should be addressed. 

 The overall impression of the quality of Lighttpd 1.4.x as a product can vary quite a lot depending on where you're looking. So, seeing Lighttpd in retrospect: 

 === Basic design, features, performance === 
 There is no denying that "less is more" sometimes, Lighty being one of those cases. The basic design laid out by Jan is ambitious enough to provide a good number of features, yet retaining the "lightweight" overall feel of the program. 

   * Overall: Good. 

 === The code === 
 It builds without ''too'' many warnings ;-). The fact that it ''has'' a test framework is just super. 

   * The tests need to be maintained (maybe assigned/delegated to a specific developer). 
   * Successfully executing the tests should be a part of the release procedure :-) 

 === Documentation === 
 We have several up to date tutorials on the wiki, that's great. But for reference? 

   * Most of the documentation could move from the main web page to the wiki (to enable joint maintenance). 

 === Project group === 

   * Overall: What persons, other than Jan, are SVN commiters? What other people are accountable, and for what? see DevelopersList 

 === TODOs === 
 1.5.x is meant to 
   * fix internals which are blocking us from moving forward. 
   * do big changes that can't be done on 1.4.x-stable branch. 
   * merge most if not all duplicated code, which helps a lot on code maintaining/improving 

 the list below is meant for discussion. 

   * combine mod_fastcgi, mod_cgi, mod_scgi and mod_proxy into mod_proxy_core 
     and protocols around it. They all cut'n'pasted from mod_fastcgi anyway. 
     * the core provides  
       * config handling 
       * connect/retry retry on failure 
       * fork/restart worker child on dead. (easier to improve native win32 support) 
       * balancing 
       * x-sendfile 
     * the protocol backends take care of 
       * preparing the environment (most cgi env code can be shared) 
       * encode/decode data 
       * handle io 
   * introduce a new io-subsystem which allows filtering content incoming and 
     outgoing data 
     * mod_uploadprogress can track the progress of an upload 
     * mod_deflate can compress content 
     * mod_multiplex can reroute content to other connections 
     * mod_layout can replace tags in the outgoing stream 
     * consider support for asynchronous file io (most likely emulated using threads rather than native aio calls) 
   * make the core aware of max-workers 
     * combines server-status 
     * synchroniced logfiles 
     * perhaps make it memcache/shm/mmap based for cluster-wide stats 
   * combine most of config handling into core, including: 
     * alloc/free plugin data 
     * init default values 
     * insert values from config (into plugin data) 
     * patch(pick) values from plugin data for connection. 
       this is done by calling a function ptr, but we can kill the string comparisons, lower or higher performance? 
   * apply %n to other config option. 
     (such as document root. user might get confused what do or doesn't support %n, but it's seems hard to apply all the options.) 
   * find a way to solve module order problem: 
     * sort the "user enabled module" by the builtin "ordered module list", but 3rd party module have no luck on this way. 
     * or add more "handling stages", and depends on "stage order" instead of "module order". this is a bit too complex. 
     * or ... (and your solution here)