apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Branko Čibej <br...@xbc.nu>
Subject Re: apr-iconv 1.0
Date Fri, 25 Jun 2004 21:04:09 GMT
William A. Rowe, Jr. wrote:

>At 12:35 PM 6/25/2004, Branko ÄŒibej wrote:
>  
>
>>David Reid wrote:
>>
>>    
>>
>>>If the answer to the question "does what we have now work" is "yes" then
>>>apr-util 1.0 is good to go.
>>>
>>>      
>>>
>>+1
>>
>>The apr-iconv API is unfortunate, and the fact that it doesn't support transliteration
like GNU libiconv is worse, but most uses of apr-iconv will be through the apr-util xlate
wrapper, so it's not so important to clean up the API.
>>
>>Also, if we're going to change the API, we might as well move base it on the iconv-2.0
version (we're currently using the 1.0 as a baseline).
>>    
>>
>
>Is there a non-[l]gpl iconv 2?
>
The one we're using is version 1.0 from Konstantin Chugev, and IIRC it's 
a BSD thing. In the meantime, he's released 2.0.

>I found one is freebsd ports, that I think is the
>current (and has a new maintainer.)  Want to be certain we are speaking
>about the same one.
>  
>
I think we are, yes.

>I'm tempted to say we explicitly declare libapriconv as a private library of
>libaprutil, just as the bundled expat is, with no public api support.  That
>simplifies things to simply @doxygenate the apr-iconv header to say
>this is an internal api for use by apr-util, and pointing them to those
>functions.
>
>The goal would be to allow us to redo the latest bsd-licensed iconv to
>support other platforms, with or without apr, as an opaque dependency.
>  
>
+1. I don't see why we'd need a separate apr-iconv public API, since we 
already have apr_xlate.


-- Brane


Mime
View raw message