apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Garrett Rooney <roo...@electricjellyfish.net>
Subject Re: [PATCH] the beginnings of multicast support
Date Sun, 06 Apr 2003 15:35:25 GMT

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 


Mime
View raw message