Henri Gomez wrote: > > > > 1. We don't need ajp_env_t (use the pool directly) 2. We don't need > > ajp_idef and ajp_ilink (use the sockets directly) > > well ajp_ilink_t make provision for more than TCP/IP socket, > we could at later time unix socket :) >
If someone will ever crate a unix socket support, then we'll write another transport layer that will eventualy cast the apr_socket_t to some other struct. Othervise we are back on jk/jk2. Lets make that simple so one can easily rewite the functionality for other thansport layers rather to abstact in advance. > Also we could add here some statistics, ie number of requests > handled on such link. It's just a simple abstraction level. > There is no need for that, at least I cannot see it. The stats are maintained on worker level not for each particual socket. The socket itself will be acompanied with conn_rec that will hold all the rest params. So where you have a socket, use the conn_rec too. We can later obtain both of them either from proxy_conn_rec struct or any other, but the api will remain untact. MT.
smime.p7s
Description: S/MIME cryptographic signature
