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.  

      o the core provides  

            + config handling  

            + connect/retry on failure  

            + fork/restart worker child on dead. (easier to improve native win32 support)  

            + balancing  

            + x-sendfile   

      o 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  

      o mod_uploadprogress can track the progress of an upload  

      o mod_deflate can compress content  

      o mod_multiplex can reroute content to other connections  

      o mod_layout can replace tags in the outgoing stream  

      o consider support for asynchronous file io (most likely emulated using threads rather than native aio calls)   

* make the core aware of max-workers  

      o combines server-status  

      o synchroniced logfiles  

      o perhaps make it memcache/shm/mmap based for cluster-wide stats   

* combine most of config handling into core, including:  

      o alloc/free plugin data  

      o init default values  

      o insert values from config (into plugin data)  

      o 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:  

      o sort the "user enabled module" by the builtin "ordered module list", but 3rd party module have no luck on this way.  

      o or add more "handling stages", and depends on "stage order" instead of "module order". this is a bit too complex.  

      o or ... (and your solution here)                ]]>