On Sunday, April 6, 2003, at 11:28 AM, Jeff Trawick wrote:

Garrett Rooney wrote:
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.)

i'd be willing to consider an extended socket options interface for this kind of stuff, since that would be quite natural for a unix programmer coming to apr (that is how all this stuff is done in unix land after all), but i'm curious how it would feel for a win32 (or netware or os/2 or whatever) coder. how is multicast support usually done on other platforms?


that said, i'm still leaning a little towards separate functions, since the catch-all 'just set a socket option' thing has always seemed kind of weird to me, and i've never liked the way you pass some random data structure into setsockopt/getsockopt depending on what option you're setting/getting (ioctl bugs me in the same way... it often feels like it would have been cleaner to just implement separate functions, rather than trying to shoehorn all this random stuff into a few functions).

in any event, i don't hate the idea, and if it was there i'd likely have used it, but i'd like to hear from some of the non-unix people out there first.

-garrett



Reply via email to