On the surface, Curt's solution would break our compatibility rules.
But I think we can deviate in this instance;

  the modules in iconv/*.so are compiled by the apr-iconv project
  itself.  If we change both apr-iconv and its modules to now
  disambiguate the 0.9 and 1.0 modules, and we expect users to
  install the iconv/*.so files that match libiconv.[so|dll],
  have we broken compatibility?

Second, clearly, we must respect APR_ICONV_PATH, but we can do so
after considering APR_ICONV1_PATH and the path of the iconv module
itself, true?

In fact, my gut tells me:

  1. take our path to libapriconv-1.dll on Win32, and suffix a new
     "apriconv.1/" directory to it.  Search here first.  It's both
     explicit, it's the internal expectation of apr-iconv, and
     applies the principal of least surprise.

for users who don't follow the apriconv.1/ convention;

  2. take the user's given APR_ICONV1_PATH, if specified, to help
     resolve where they chose to locate the iconv files.

and for users who haven't done anything since 0.9.x...

  3. take the given APR_ICONV_PATH, if specified.  Curt's proposal
     to change the signature should help avoid loading invalid .so
     modules and dying in a segfault.  The module would simply not
     be found.

On unix and other platforms where we can't determine the actual
path of the libapriconv-1.so file, life would go on, and we would
follow steps 2 and 3 above.

Does this seem rational to everyone?

At 07:51 PM 3/16/2005, Curt Arnold wrote:

>On Mar 16, 2005, at 7:32 PM, Justin Erenkrantz wrote:
>>If you are adding a symbol, yes, it'd be 1.1.0.  But, under our compatibility rules, it'd have to retain APR_ICONV_PATH as a define in addition to APR_ICONV1_PATH.  -- justin
>
>Unfortunately the problem is that APR_ICONV_PATH may find you incompatible (0.9.x) modules and if you attempt to use them, you die a most horrible death.  Either the existing path needs to be ignored or there needs to be a method of detecting 0.9.x encoding modules and refusing to load them.
>
>One possibility would be to add use difference values for ICMOD_UC_CCS and ICMOD_UC_CES (currently 0x100 and 0x101) so that 0.9.x modules would not be recognized as valid encoding modules for a 1.0.x implementation.  That would also have the benefit of APR 1.x modules not crashing a 0.9.x implementation.
>
>As it stands it is a pretty horrible bug.  If you have an app that uses apr-iconv-1.x, it will work fine until Subversion is installed and all things start crashing.
>
>