You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by "William A. Rowe, Jr." <wr...@rowe-clan.net> on 2007/07/28 05:24:00 UTC
apr_socket_vars_set
http://people.apache.org/~wrowe/mod_remoteip.c is an example of how
borked our current API is. There's no need, in this case, to allocate
yet-another-apr_sockaddr_t, but there seems to be no sane way to just
go ahead and fill in the existing one.
No set function anymore for addr/port/etc? That sort of blows.
Any suggestions on how we can improve the situation? How about starting
with exporting apr_socket_vars_set?
Bill
Re: apr_socket_vars_set
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
I'm investigating this. Since it's all a major regression since 0.9.x
(where we were able to introspect the sockaddr_t and play games within it)
we really need to round out this somewhat crufty API before 1.3.0 IMHO.
Bill
Brian J. France wrote:
> WOW! I will be converting a module from 1.3 to 2.x soon that will be
> doing close to the same thing.
>
> I am all for making this as easy as possible.
>
> Brian
>
>
> On Jul 27, 2007, at 11:24 PM, William A. Rowe, Jr. wrote:
>
>> http://people.apache.org/~wrowe/mod_remoteip.c is an example of how
>> borked our current API is. There's no need, in this case, to allocate
>> yet-another-apr_sockaddr_t, but there seems to be no sane way to just
>> go ahead and fill in the existing one.
>>
>> No set function anymore for addr/port/etc? That sort of blows.
>>
>> Any suggestions on how we can improve the situation? How about starting
>> with exporting apr_socket_vars_set?
>>
>> Bill
>
>
>
Re: apr_socket_vars_set
Posted by "Brian J. France" <li...@firehawksystems.com>.
WOW! I will be converting a module from 1.3 to 2.x soon that will be
doing close to the same thing.
I am all for making this as easy as possible.
Brian
On Jul 27, 2007, at 11:24 PM, William A. Rowe, Jr. wrote:
> http://people.apache.org/~wrowe/mod_remoteip.c is an example of how
> borked our current API is. There's no need, in this case, to allocate
> yet-another-apr_sockaddr_t, but there seems to be no sane way to just
> go ahead and fill in the existing one.
>
> No set function anymore for addr/port/etc? That sort of blows.
>
> Any suggestions on how we can improve the situation? How about
> starting
> with exporting apr_socket_vars_set?
>
> Bill