Remy Maucherat wrote:
Henri Gomez wrote:
Second reference to mod_coyote ?
Should we retains this one ?
Maybe ;)
We have two connectors planned. This one will use AJP, while the other would use JNI, so we need two, different, non confusing names. So naming this mod_jk3 would be bad, just like naming the two mod_coyote1 and mod_coyote2.
So when will we get all these new shiny toys ? :)
Well we should first discuss for :
- a name :)
- what features will be mandatory in the initial release.
- library/modules repartition
You speak about AJP and JNI, so I suggest 2 differents projets :
mod_ajp
mod_jni
Both will be Apache 2.x modules to link an Apache web-server with
tomcat(s) using AJP 1.3++ (AJP 1.4) protocol (mod_ajp) or JNI connectiviy (mod_jni).
I could works on mod_ajp, taking the best parts of jk/jk2, and putting
the basic bricks in an ajp library. Of course we'll need to see how to
make this ajp library with real world, for instance I think we could follow the Mladen idea, ie having a configuration structure (tree) located in memory and updated via call to the API :
ajp_config_t * create_ajp_config();
int add_ajp_worker(ajp_config_t * conf, ajp_worker_t * wrk);
int remove_ajp_worker(ajp_config_t * conf, ajp_worker_t * wrk);
int update_ajp_worker(ajp_config_t * conf, ajp_worker_t * wrk);
int destroy_ajp_config(ajp_config_t * conf);
Ad minima we should have workers in the configuration.
To remove the work to rewrite the URI to worker part, we could start with a mapping using Apache 2 directive ie Location/EnvVars/Files...
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
