Project

General

Profile

Ideas » History » Revision 2

Revision 1 (icy, 2008-10-11 17:43) → Revision 2/7 (nitrox, 2009-04-28 15:08)

h1. Ideas 

 {{>toc}} 

 h2. Generic things 

 * Use ragel for parser generation 
 * Kick automake, probably use cmake instead 
 * Split off nice tools into separate trees (spawn-fcgi, fcgi-stat-accel) 
 * Use glib2 for containers and other things (modules, logging, ...?) 
 * Never use global variables. Never! 

 h2. Get hackers and company´s in touch 

 * http://www.cherokee-project.com/contribute.html - Bounty Hunting, get company´s to spent a few bucks on things they want and ask community to write a module or extension and earn the money, nice idea! Users may submit their patches/modules and submit it to the dev´s, who then decide what gets implemented and who wins the price. 

 h2. Angel 

 * should perhaps use a separate config file 
 ** define sockets / ssl options there? so sockets are maintained by angel for graceful restart? 
 * plugins (e.g. for fcgi spawning) 
 * perhaps a thread for error logging so error messages do not overlap? 


 h2. Config structure 

 * Generic backend 
 * Old config style frontend 
 * Lua frontend 
 * Linear request handling without confusing conditional blocks (still with conditionals of course) 
 * A nice interface to load/unload addtional config options (e.g. for sql-vhosts) 
 * Better interface for asynchronous config handling (again for sql vhosts) 

 h3. Options 
 > struct option 

 We have some different structures for options: 
 * Boolean (gboolean) 
 * Integer (gint) 
 * String (GString*) 
 * Array (GArray*) - an ordered list of sub options 
 * Hashtable (GHashTable*) - mapping from strings to sub options 

 For some things like rewrite we used associate arrays till now we could use an array of (key, value) pairs, perhaps use a special syntax for that ( "abc": "xyz" for ordered key-value pairs instead of "abc" => "xyz" for hashtables). 

 h3. Internal options 

 Every module can define a list of options (identified by name like "debug.log-something"). For each option there is a gpointer entry in a per connection table, in which the module can find the needed value by an index. 

 The definition for a option includes: 
 * Name 
 * Type (the same values as for option + perhaps a value for "custom") 
 * Two functions: parse_option and free_option (see below) 

 Two ideas for the index: 
 * Modules register every option manually and save a returned index in there plugin structure. 
 * Modules define a list of options and use a module-base-index (from plugin structure) + the local index for there list. 

 As it may be very useful for a module to have more than a "option struct", e.g. to safe filedescriptors (access.log), so we register every possible option with an option-specific parser. The default is to just use the value from the option struct. 
 This parser returns a gpointer, which will be put in the corresponding place in the connection table if it the options gets set. 
 To enable unloading of options there is also an free_option func which should release the memory. 

 h3. Actions 

 In the current lighttpd versions options are used to control which backend handles a request - this often depended on the order of loaded modules and some other things only a few people knew (or knew where to find). 
 We want to replace this with "actions": we explicitly call some functions and know what they will do. 

 There are some different types of action: 
 * Set config option 
 * Execute sublist 
 * If conditional is true execute sublist 
 * call a special handler (provided by some module) 

 every action returns one of the following codes: 
 * ERROR - an internal error, stops connection handling 
 * GO_ON - nothing special happened 
 * BREAK - we finished a step like doc-root finding and want to skip other doc-root handling actions 
 * FINISHED - we now know how to handle the request. stop config handling here 
 * WAIT_FOR_EVENT - come back later, remember current position 

 BREAK breaks all sublist handling until a "special" list is hit; the simple config will have hardcoded special lists, the lua will have dynamically ones.