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
nightmarish.
Bill
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.
