DevelopmentProceduresR1 5 » History » Revision 12
Revision 11 (Anonymous, 2006-06-18 11:46) → Revision 12/15 (Anonymous, 2006-12-29 12:43)
== 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 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. users might get confused as to what does or doesn't support %n, but it 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.
* sparsely assign each module a numeric id and use this to determine loading order.
* or ... (and your solution here)