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