apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@rowe-clan.net>
Subject Re: apr-iconv 1.0
Date Tue, 29 Mar 2005 22:55:36 GMT
This is the original thread we discussed apr-iconv going forward
in 1.0.  It seemed at the time our conclusion was that apr-iconv
would be an internal implementation, not for consumption by the
outside world.

We have an open issue that we are finding some iconv/*.so modules
outside of -our- install, e.g. the gnu iconv, bsd iconv,
apriconv.dll and apriconv-1.dll modules can trip over one another.

Two weeks ago Curt and I kicked around solutions.  Nobody else
responded to the thread, so this post is mostly informative and
for history.

The arguments been made that we should respect APR_ICONV_PATH first,
then historical locations, then use new semantics.  That would NOT
eliminate the conflict.  In hindsite, I'm against adding a special
APR_ICONV_1_PATH, instead, I'll make APR_ICONV_PATH the very last
place we look.

The new layout will use PATH (on win32, if we update for unix,
then LD_LIBRARY_PATH on unix, SHLIB_PATH on hpux) to find the
directory (e.g. apriconv-0 or apriconv-1).  Upon the next release
of httpd, we will entirely eliminate the possibility of colliding
with iconv/.so files from another library provider.

Since we presume apriconv[-1].dll includes {charset}.so files,
any change we make to the .dll will come with an accompanying set
of .so files.  If we change this and roll out a new release, those
installing the new version will find it installs as the new layout
expects.  I can't see a 'binary compatibility' problem there.

If there are any thoughts, please voice them now, as I'll be fixing
the code tomorrow.  The httpd'ers are anxious for a beta, and all
these collisions between log4cxx, svn, httpd etc are going to become


At 11:46 AM 7/2/2004, Branko Čibej wrote:
>William A. Rowe, Jr. wrote:
>>At 06:41 PM 7/1/2004, Branko Čibej wrote:
>>>Thoughts? I think 1.0 is an auspicious time to make this change, especially if
we declare apr-iconv to be an implementation detail of apr_xlate.
>>The nifty bit is, if we declare apr-iconv to be an internal, implementation
>>detail of apr_xlate - we are free to adopt your suggestions in 1.0.1 :)
>That's true.
>>What is troubling us most, at this instant, are those things that change
>>the API in such a way that developer's code would be broken fixing the
>>problems of APR 1.0.0.  As long as they are internal details (default
>>pathing, etc) then we won't be troubled by getting it right a little later.
>Then I suggest we really do close off apr-iconv. This means the apr-iconv headers shouldn't
get installed, right? Among other things.

View raw message