Mladen Turk wrote: > Hi, > > Since there has been general concensus that we should use the APR for > every supported API call. > Here is my design proposal. > > General: > [ ] Drop HAS_APR flags and dissalow building of JK2 without APR > [ ] Keep everything like it is (the rest doesn't interests me)
As I said, my option is: [X] Leave the existing components, create all new components based on APR. and make sure plugability works. In future - deprecate the non-apr components after 2.0 is released and default to apr-only components in 2.1, remove non-apr components after 2.1 is released ( i.e. for 2.2 ). I think that maximises the stability of the code. > Regular expressions: > [ ] Add pcre from httpd-2.0 to the common/pcre > [ ] Add pcre from httpd-2.0 to the srclib/pcre > [X] Wait if pcre ever comes to the apr-util If we wait to much - one of the first 2 choices. > Pools: > [X] Use the real apr_pool_t. > [ ] Keep the jk_pool_apr wrapper renaming it to the jk_pool With the mention: use the real apr_pool_t in new code, let jk_pool_apr in the code related to component model ( and all new apr components can get and use the real apr_pool_t from jk_pool_apr struct ). > Sockets: > [x] Use only apr_socket and drop the socket, renaming apr to socket. > [ ] Keep supporting socket. Use only apr_socket and default to it for 2.1, but without removing the old jk_socket ( until 2.2 ) > File I/O: > [x] Use the APR for file i/o replacing stdio/stdlib calls > [ ] Keep the old fopen/fwrite/etc... code Same as before. > Static buildings: > [x] Enable Static/Dynamic APR builds of JK2 for non-Apache2 connectors > [ ] Enable only dynamic builds -- Costin -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
