any comments?
If APR had support for extended socket options (i.e., anything other than single-integer option data, would you have still chosen to create separate functions or would you have chosen to use socket options for multicast, as is done with existing socket interfaces?
Meanwhile, apr_socket_ext_option_[set|get] ("ext" for extended, meaning that it uses a context-specific data type of arbitrary size could be put to use for other things (ulterior motives here :) I'm frustrated at the moment because I can't even retrieve a pointer via a socket option.).
With functions, you're going to end up with five or so different functions for the common multicast operations, with dummy versions in multiple places potentially, and any other feature that isn't handled with the int limitations of the current socket option API is going to need something else as well.
(I'm happy to do the extended-option work, I'm just curious if we have a possible use here.)
