At 12:36 AM 3/30/2005, Curt Arnold wrote: >On Mar 29, 2005, at 11:13 PM, William A. Rowe, Jr. wrote: > >>At 10:09 PM 3/29/2005, Curt Arnold wrote: >>>I'm unclear on the proposed resolution. Does it include a mechanism to >>>distinguish apriconv-1 encoding modules from apriconv-0 modules either by >>>changing the module signature or name? >> >>I believe we should do that, too. But it seems that some want >>us to use an 'external' iconv implementation, at least, as of >>the next major release of apr-util. With the files residing >>in /apriconv-1/*.so I'm less concerned with the signature. > >Are you expecting the apriconv-1 directory to be on the PATH or >LD_LIBRARY_PATH
yes. >or relative to a directory on the PATH or LD_LIBRARY_PATH? Well the directory apriconv-1 will reside in a directory pointed to by PATH/LD_LIBRARY_PATH/SHLIB_PATH. And (at least on win32) within the cwd as we also discover binaries that way. The theory is simple. We -found- libapriconv-1.so/.dll. We'd already loaded it. How? Because it resided in exactly those paths, or the subdirectory of the startup dir on win32. The trivial rule is that libapriconv-1/ directory must sit beside libapriconv-1.so/.dll. >If it is on the PATH or LD_LIBRARY_PATH, then this is the continued >possibility of collision with modules from other iconv implementations, if it >is relative to an directory on the path, then I would expect that you would >need add a decent amount of complexity to accomplish that. Not really. We concatenate two strings, or three. >I would think it may be simpler to have modules named apriconv-1-ENCODING.so >or .dll and have dlopen or LoadLibrary find them with their existing library >search mechanisms, but I could understand if that was undesirable for other >reasons. Hmmm. String concats are string concats. Visually, I believed a directory libapriconv-1 was more clear. I don't think adding the extra filename information buys us anything, since -all- iconv implementations have always shared the concept of a separate dir for loadable modules. >>>Without some mechanism to distinguish encoding modules, it really doesn't >>>matter what order the paths are evaluated? If there is a mechanism, it >>>shouldn't hurt to evaluate APR_ICONV_PATH first? >> >>Of course it would, because we would still have to iterate >>multiple .so files to find the correct one. This is a huge >>performance hit. >> >>So let me inquire - have you authored a custom (charset).so file, >>or intend to do so? > >No, I have no intention to do that. At this point, the resolution to the >issue does not effect log4cxx since it will continue to hack apriconv to embed >the encodings into log4cxx.dll and liblog4cxx.so. >You need to do what is right for httpd and/or Subversion. Ack. And I hope - do something that log4cxx ultimately adopts. >>Again, the consensus on list was that apr-iconv >>was an implementation-internal detail of apr-util. With the next >>release, implementors/users are expected to install the directory >>apriconv-1 in parallel to apriconv-1.so [.dll]. APR_ICONV_PATH >>would be searched last, to pick up those exceptions/custom charset >>modules. We wouldn't hit iconv/ at all (unless the user asks us >>to through APR_ICONV_PATH. > >Since Subversion sets APR_ICONV_PATH, there is still the possibility of >finding an apriconv-0 encoding module if the installation is damaged (or the >developer decides not to distribute some obscure encoding) or a new encoding >gets added to Subversion and/or apriconv-0. Right, except that we would seek APR_ICONV_PATH last. Minimize the chance of a collision. But certainly, not exclude every possibility. >>So I'm confused if this solution doesn't resolve the issues of all >>users. Please explain further. >> >>On your point of avoiding conflicts by changing the signature, yes >>I would be -happy- to entertain a patch, if you want to post one in >>the next day. I'll be putting together my changes tomorrow eve, >>and would be easily able to integrate your suggestion if you care >>to offer the patch. I don't see it as a substitute for searching >>for the right file, but I see it as added security against loading >>the wrong module. > >By changing the signature, I meant changing the value of ICMOD_UC_CCS and >ICMOD_UC_CES (currently 0x100 and 0x101). Ack. >I don't know if this method of module identification is used elsewhere and if >so, what other values are currently in use. If the encoding modules can't be >distinguished by name, I think it is essential that they have a different >magic value. Otherwise, you are just reducing the chances of a catastrophic >failure by checking APR_ICONV_PATH last, not eliminating it. Yes. >Putting myself in the position of the developer of some hypothetical app (and >I couldn't have an iconv2 based solution), I would prefer that apriconv-1 >encoding modules be named something like "apriconv-1-utf-8.dll" or >"libapriconv-1-utf-8.so" and located using the established library search >algorithms in dlopen or LoadLibrary. In deployment, these would likely be >placed in the same directory as aprutil-1.dll or libaprutil-1.so or the >executable if linked against a static aprutil-1. APR_ICONV_PATH could be >ignored. If the user really wanted a new encoding, they could either place it >in an already searched directory or add the directory to PATH or >LD_LIBRARY_PATH. > >However, it would be good if we could get some comment from a Subversion >developer. Agreed, and Branko's watching this thread. Bill
