apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe Jr." <wr...@rowe-clan.net>
Subject Re: [VOTE] Release apr-util 1.5.0
Date Wed, 22 Aug 2012 17:14:10 GMT
On 8/22/2012 10:12 AM, Bert Huijben wrote:
>> -----Original Message-----
>> From: William A. Rowe Jr. [mailto:wrowe@rowe-clan.net]
>> Sent: zondag 12 augustus 2012 19:40
>> To: dev@apr.apache.org
>> Subject: Re: [VOTE] Release apr-util 1.5.0
>>
>> On 8/10/2012 1:05 PM, Stefan Fritsch wrote:
>>> Thanks for the detailed tests.
>>>
>>> On Friday 10 August 2012, Rainer Jung wrote:
>>>> If you don't need to release before, I would like to fix the LDADD
>>>> use over the weekend, but it is not a show stopper.
>>>
>>> It seems I will be busy in the next few days. It is unlikely that I
>>> T&R 1.5.1 before next Wednesday.
>>>
>>>> Another nice to have would be an expat update to 2.1.0.
>>>
>>> Has anyone looked into this before and knows how much work this is?
>>
>> I have an alternate suggestion as of 1.5 - to drop our embedded expat
>> just as we did in trunk.  Require the user to obtain the (now once
>> again maintained) expat package.
>>
>>> Another nice to have fix would be support for newer Berkley DB
>>> versions (PR 53684).
>>
>> And I'd also like to incorporate the rfc implementation of punycode
>> encode/decode for use by any i18n domain features of our consumers,
>> such as httpd or even client apps.  Would anyone mind, if I can get
>> this into the tree by tuesday aftn?  As 1.5.0 wasn't released, I don't
>> think the binary compatibility is an issue just yet.
> 
> Ping?
> Any update on the punycode support?
> 
> I'm not really part of the apr(-util) project, but I would like to see a new release
after the failed 1.4.2 attempt months ago.

The code exists already in a licensable form as part of the spec, I believe.

  http://tools.ietf.org/html/rfc3492#appendix-C

This can be made more usable with pools, etc with a pretty trivial effort.
Before I start, though,

Is anyone aware of a better implementation under an AL-compatible license?
>From Appendix B;

B. Disclaimer and license

   Regarding this entire document or any portion of it (including the
   pseudocode and C code), the author makes no guarantees and is not
   responsible for any damage resulting from its use.  The author grants
   irrevocable permission to anyone to use, modify, and distribute it in
   any way that does not diminish the rights of anyone else to use,
   modify, and distribute it, provided that redistributed derivative
   works do not contain misleading author or version information.
   Derivative works need not be licensed under similar terms.




Mime
View raw message