DevelopmentProceduresR1 5 » History » Revision 14
Revision 13 (Anonymous, 2006-12-29 12:43) → Revision 14/15 (Anonymous, 2012-08-11 10:42)
h2. 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:
h3. 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.
h3. 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 :-)
h3. 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).
h3. Project group
* Overall: What persons, other than Jan, are SVN commiters? What other people are accountable, and for what? see DevelopersList
h3. 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)