Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Message-ID: <3FD6184C.2080305@stason.org>
Date: Tue, 09 Dec 2003 10:45:32 -0800
From: Stas Bekman <stas@stason.org>
Organization: Hope, Humanized
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030630
MIME-Version: 1.0
To: trawick@attglobal.net
Cc: dev@apr.apache.org
Subject: Re: yanking some unnecessary networking apis from 1.0...  time to
 holler
References: <3FCCB664.8020604@attglobal.net> <20031204152240.H3654@lyra.org>
 <3FD522E2.4020104@stason.org> <3FD5A87F.4030308@attglobal.net>
In-Reply-To: <3FD5A87F.4030308@attglobal.net>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Jeff Trawick wrote:
> Stas Bekman wrote:
> 
>>>> remove:
>>>>   apr_sockaddr_port_get() - caller can read from sockaddr directly
>>>>   apr_sockaddr_ip_set() - limitation of IPv4 n.a.s. is bogus
>>>>                         caller should use apr_sockaddr_info_get()
>>>>
>>>> shrug:
>>>>   apr_sockaddr_port_set() - bad for caller to set in
>>>>                          sockaddr directly; I'm not sure how useful
>>>>                          it is to use apr_sockaddr_info_get() but
>>>>                          then change the port later
>>>>
>>>> but leave:
>>>>   apr_sockaddr_ip_get() - this does interesting work that we don't
>>>>                         want to do ahead of time just in case
>>>>                         this info will be needed
>>>>
>>>> Also, change the docs for apr_socket_connect() to remove the hint 
>>>> about passing NULL for the sockaddr.
>>
>>
>>
>> There is a problem with doing this. These functions are not deprecated
>>  in the 9.x branch. So you should at least commit .h fix that 
>> deprecates them.
> 
> 
> done, good idea

Thanks Jeff.

>> I don't think it's very developer-friendly to nuke public functions 
>> without first deprecating them.
> 
> 
> there is clearly an order problem though...  yes we should mark things 
> deprecated in 0.9 API definitions, as most removed or renamed things 
> were, but if something different needs to be cleaned up for 1.0 API here 
> at the last minute then there will be no advance warning

As a user of apr, for me the best value in "deprecated" doc entries is that 
they point to the replacement function. If it's forgotten to be added I've to 
wander around trying to figure what function I should be using instead.


__________________________________________________________________
Stas Bekman            JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/     mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com