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