Re: [network] An RFC - updated

Hi Michel,
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.
The pseudo-tokens would work as long as they weren't ambiguous with allowed machine names in that network. I think a simple layer to register network objects (so you don't get them all linked in<g>), plus a fully general text-to-address object mapping would be a reasonable facility. Again, though, I view this as a (good) simplified use case and would still want control over the life-time of these objects (see other posts for the sad story<g>). I do recognize my concerns here are probably not too common, but all this might mean is that an http_get wrapper would be overloaded on url and address_ptr. The former would call the later after a lookup. Best, Don __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

Don G wrote:
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.
The pseudo-tokens would work as long as they weren't ambiguous with allowed machine names in that network.
Of course amibuity can be risked in corner cases, but selecting the tokens to minimize this and an escaping mechanism could make names and special names unambigous. /Michel
participants (2)
-
Don G
-
Michel André