* William A. Rowe, Jr. ([EMAIL PROTECTED]) wrote : > At 06:19 AM 10/30/2002, Thom May wrote: > >Ok, here goes (this is much more practical than the patch): > > Agreed. However, I have some mixed feedback here. The long > and short of it; commit apr_gid and apr_uid changes already, > and apr_filepath_name_get, but take one last look at socket before > committing it. Perhaps hold off on time. And absolutely don't commit > apr_file_[l]stat just yet for reasons I note below. > sure. I just don't want to see this stuff get thrown out of the 1.0 window :-) (and I want 1.0 soon) ;-)
> Here's the tour... > > > >apr_file_stat from apr_stat > >apr_file_lstat from apr_lstat > > Bah... as discussed, these don't operate on apr_file_t's, they > don't qualify as apr_file_ operations. Perhaps as apr_finfo_stat > etc they could be renamed. > hrm, I must have missed this bit of the last discussion, or my memory is failing. OK, these are on hold. > > >apr_socket_shutdown from apr_shutdown [...] > >apr_socket_recv from apr_recv > > I was about to make the old complaint that these api's are overkill, > standard names, etc. And then I considered apr_file_t and it's functions. > So +1 here, even over those old objections, for each function which > operates on (has a first argument of) an apr_socket_t. But there are > exceptions... right. > > > >apr_socket_filter_accept from apr_socket_accept_filter > > This is in the apr_socket_accept family, why rearrange order here? > good point. > >apr_hostname_get from apr_gethostname > >apr_port_addr_parse from apr_parse_addr_port > >apr_sockaddr_fromname_set from apr_getservbyname > >apr_sockaddr_hostname_get from apr_getnameinfo > > Bleh. Ick. There isn't consistency here. These will be difficult > for coders to recall. They are a little rough, don't you think? > I kind of agree. the last two are nasty, but consistent, the first one... ber. the second one i think is better in the changed form. > >apr_socket_file_create from apr_socket_from_file > > Hmmm. What is it creating? How? This name is pretty ambigious. > This one is icky. I hate the current name's lack of coherency with anything else, but I don't know what to call it. > > >apr_time_exp_gmt_get from apr_implode_gmt > > Grumpf. Another hard to use name... I have to look at the big time > picture again to see if that's the right solution. > It's in line with the rest of the explode/implode functions now.
