You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by "William A. Rowe, Jr." <wr...@rowe-clan.net> on 2005/03/17 01:38:09 UTC
Hold horses, 1.1.1 solution
It occurs to me the issues can be localized to apr-iconv.
As long as the prerequisite is the as-yet-unreleased apr 1.1.1
with the answer to the tangle codepage file search issue, then
I believe the apr and apr-util tarballs themselves will be fine.
Cracking on getting an appropriate patch together for apr-iconv
trunk, after some brief comments we will move ahead w/ tagging
an apr-iconv 1.1.1.
Yes, it's a short delay between apr/apr-util being done for
Unix v.s. Win32, but it beats rerolling apr.
Re: Hold horses, 1.1.1 solution
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
At 07:32 PM 3/16/2005, Justin Erenkrantz wrote:
>--On Wednesday, March 16, 2005 7:02 PM -0600 "William A. Rowe, Jr." <wr...@rowe-clan.net> wrote:
>
>>This would be a minor bump, if not a major bump due to our oversight.
>>Certainly can't be a subversion bump since it changes the user-visible
>>usage of APR_ICONV_PATH (to APR_ICONV1_PATH) I thought about some
>>extra punctuation and decided dashes weren't kosher, an extra
>>underscore seems unnecessary. If anyone feels differently, holler.
>
>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
Actually our compatibility rules say nothing about external
env vars. I agree in spirit. However, any _application_ which
horks with APR_ICONV_PATH is potentially breaking existing apps.
Now What?
I'd almost be partial to both APR_ICONV0_PATH (ewww... that 0 does
look too much like an O) and APR_ICONV1_PATH. Fallback, for -both-
would be APR_ICONV_PATH.
A better solution, over time I believe, is very Win32 specific.
We can inquire for the full pathname of the 'libapriconv.dll'
library. My suggestion is that we prepend that path to -any-
path list given. Alternately, we insert it between APR_ICONV1_PATH
and APR_ICONV_PATH.
This only solves the whole problem if the 'default path' for
apriconv-1 modules is renamed from iconv. Otherwise, the same
conflict will persist.
Bill
Re: Hold horses, 1.1.1 solution
Posted by Curt Arnold <ca...@apache.org>.
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.
Re: Hold horses, 1.1.1 solution
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
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.
>
>
Re: Hold horses, 1.1.1 solution
Posted by Curt Arnold <ca...@houston.rr.com>.
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.
Re: Hold horses, 1.1.1 solution
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On Wednesday, March 16, 2005 7:02 PM -0600 "William A. Rowe, Jr."
<wr...@rowe-clan.net> wrote:
> This would be a minor bump, if not a major bump due to our oversight.
> Certainly can't be a subversion bump since it changes the user-visible
> usage of APR_ICONV_PATH (to APR_ICONV1_PATH) I thought about some
> extra punctuation and decided dashes weren't kosher, an extra
> underscore seems unnecessary. If anyone feels differently, holler.
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
Re: Hold horses, 1.1.1 solution
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
At 06:43 PM 3/16/2005, Justin Erenkrantz wrote:
>--On Wednesday, March 16, 2005 6:38 PM -0600 "William A. Rowe, Jr." <wr...@rowe-clan.net> wrote:
>
>>Cracking on getting an appropriate patch together for apr-iconv
>>trunk, after some brief comments we will move ahead w/ tagging
>>an apr-iconv 1.1.1.
>
>You probably mean apr-iconv 1.0.3. (We're at 1.0.2.) -- justin
This would be a minor bump, if not a major bump due to our oversight.
Certainly can't be a subversion bump since it changes the user-visible
usage of APR_ICONV_PATH (to APR_ICONV1_PATH) I thought about some
extra punctuation and decided dashes weren't kosher, an extra
underscore seems unnecessary. If anyone feels differently, holler.
The same bug affects any unix or other users of apr-iconv, fwiw (zero).
Re: Hold horses, 1.1.1 solution
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On Wednesday, March 16, 2005 6:38 PM -0600 "William A. Rowe, Jr."
<wr...@rowe-clan.net> wrote:
> Cracking on getting an appropriate patch together for apr-iconv
> trunk, after some brief comments we will move ahead w/ tagging
> an apr-iconv 1.1.1.
You probably mean apr-iconv 1.0.3. (We're at 1.0.2.) -- justin