I think this is a bit of a sidetrack from the goal of this patch but I agree; It would definitely be nice to be able to easily extend the API in such a manner. My goal in this particular patch was to give a set of (primarily UDP) datagram functions with an interface analogous to what existed for the stream (TCP) functions. TCP and UDP are currently the primary network technologies used today. Though DCCP (and ICMP) would be nice too. My knee-jerk opinion is that the current use of HostName and PortID already assume IPv4 protocols such as TCP and UDP more than they could. Unix socket functions for example make no use of the HostName argument at all and the UnixSocket constructor just doesn't sound like it fits the name of the type "PortID" to me. Consequently, I think making the Network module more flexible for extension would involve getting rid of the current addressing scheme and implementing some new Address type which includes not just the address, but the protocol used. So something like data Address = TCP HostName PortNumber | UDP HostName PortNumber | DCCP HostName PortNumber | UnixSocket FilePath -- Maybe also inet6: | TCP6 HostName6 PortNumber | UDP6 HostName6 PortNumber and so forth. Of course this is beyond the scope of this patch. On Thu, 2007-04-05 at 02:32 -0700, John Meacham wrote:
you might want to consider any API consequences of supporting DCCP
http://en.wikipedia.org/wiki/Datagram_Congestion_Control_Protocol
I am not saying full DCCP support is needed off the bat, but it would be nice if at some point in the future the API could be extended gracefully to support it as well as UDP as far as unreliable datagram style communication goes.
John
-- Robert Marlow MITS Co-operative Limited http://www.mits.coop/