On Mar 17, 2005, at 4:14 PM, William A. Rowe, Jr. wrote:
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?
The module approach allowed for the possibility of third-parties developing their own encoding modules. However, I think the chance that there is an apr-iconv-1.x user encoding module out there has to be pretty slight. There is no compatibility between 0.9.x and 1.x dependent modules, the identical module type code is a misleading indication that they are compatible.
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?
I think that an explicit path must be considered with a higher precedence than a default behavior. So apr-iconv has to be able to tolerate evaluating an APR_ICONV_PATH containing 0.9.x modules.
Definitely on the Windows platform, the most desirable deployment is to locate the encoding modules relative to the apriconv-1.dll and not have to bother with setting an APR_ICONV_PATH environment variable on installation.
Whether or not the module files are located in a subdirectory of the directory containing apriconv-1.dll depends on what you want to do on the Unix platforms. Would it be desirable to be able to locate encoding modules that are in the library path and not require setting APR_ICONV_PATH unless you wanted to specify an alternative location. If you were to do this, you would likely want to prefix the encoding name with something like "libapriconv-1-" resulting in module names like "libapriconv-1-utf-8.so" and place the modules in the same directory as libapriconv-1.
I would see the lookup procedure could be like:
1. Create library name by appending any prefix
2. Check for presence of module in each element of APR_ICONV1_PATH. If loadable, check signatures, if match, return module.
3. Repeat for APR_ICONV_PATH
4. Check for file relative to location of apriconv.dll (Windows only apparently)
5. Check library load path by calling dlopen() or LoadLibrary with just module name
If apr-iconv-1.x modules are distinct from other modules due to a unique prefix, then you could skip introducing a new environment variable.
