apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Curt Arnold <carn...@apache.org>
Subject Re: Hold horses, 1.1.1 solution
Date Fri, 18 Mar 2005 02:13:55 GMT

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 

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 
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 

View raw message