[boost] Re: [network] An RFC - updated

From: Michel André (michel.andre_at_[hidden])
Date: 2005-04-22 18:05:39

Peter Dimov wrote:
> Don G wrote:
> Under the address-centric model, the form of the address determines the 
> network to use. The library is free to maintain several network objects 
> under the hood, ...

I also prefer the address centric approach since it feels more natural.

Also I wonder what would be the hooks to register new network 
implementations and provide the notification mechanisms for those.

> Why I prefer tcp:/host:port instead of scheme://host? Let's get back to 
> enhancing std::fopen in a backward-compatible way. I'd expect fopen on 
> http://www.example.com to return the data stream obtained by the 
> corresponding GET query, for obvious reasons.

This is a good example on a very specific connector that posts a GET 
operation to initialize the stream for the handler in this case to treat 
an url as a file.

>>
>> All of these are forcing TCP/IP (IPv4 even<g>) concepts to the user.
>> The central idea of the abstraction I proposed is that "datagram" and
>> "stream" are the behavior-bundles to which one should write
>> protocols, not TCP/UDP or sockets. The notion of loopback and
>> broadcast can carry over from one network type to another, but these
>> textual forms do not.
> 
> 
> Yes; another manifestation of the network issue. I agree that in a 
> network-centric design your approach is preferable. In an 
> address-centric design, the TCP/IP4 broadcast address is not portable 
> between networks.

Is it a problem that the special or specific adresses is represented by 
different textual representations for different networks? I guess a 
textual representation could be devised that makes these look the same 
with some psuedo notation. Like broadcast tcp:/[broadcast]:1234, 
tcp6:/[broadcast]:1234, local tcp:/[local]:1234, tcp6:/[local]:1234, any 
tcp:/[any]:1234, tcp6:/[any]:1234 this would i guess alleviate some of 
the eventual problems.

/Michel