Actually, the apr_ function calls involved have not been approved for release, so I'd suggest this module is inappropriate for GA until that API is accepted (and clearly it's received minimal and insufficient review, which is completely unacceptable for a crypto interface in particular :)
For example, if 2.4.0 is shipped with a call to apr_crypto_error with three arguments, when the correct API takes two arguments (ctx and err, dropping the 1st driver argument), then it will make no sense when someone attempts to actually build the module. It seems stupid to ship such code in a GA release. svn rm'ing it once 2.3 is forked from trunk seems appropriate. Adding it back when apr-util 1.4 (or apr 2) is released would be trivial. On 12/27/2010 12:13 PM, Jim Jagielski wrote: > The idea is that httpd, as a release, should not really > have any dependencies on APR, as a release. My thoughts are > to include m_s_c in 2.4 even if the current releases of APR > don't support it, simply because later versions will. > > On Dec 24, 2010, at 8:40 PM, Jean-Sebastien Delfino wrote: > >> Mod_session_crypto requires a new release of APU 1.4.x or APR trunk, which >> now includes APU. >> >> After reading this thread [1], I'm not sure about your plan for this module. >> >> Is the plan to: >> - take mod_session_crypto out of 2.4? >> - keep it and base 2.4 on a new release of APU 1.4.x? >> - or use a new release of APR (which seems like a big change at this late >> point in the release)? >> >> [1] http://marc.info/?l=apache-httpd-dev&m=129105747900487&w=2 >> -- >> Jean-Sebastien >> > >
