> > And those shortcomings are more-or-less inherent in DNS - you really > > can't fix it and still have a namespace with the characteristics we > > want in DNS - e.g. federated assignment, federated lookup, and ability > > to assign names to groups of hosts or services. > > > > (some people think DNS should have only been used for host names, but > > we're long since past the time when that was a reasonable assumption) > > That's why we need a different namespace approach, which looks close > enough to the dns at the user/application level, so that the same API(s) > will work, but is architected differently. problem is, if you keep the same API, then apps that depend on that API will expect that the name space has the same characteristics as DNS, (benefits and shortcomings and everything else). so for instance they will still try to bypass DNS when DNS would have been a poor choice for them. even if the resulting architecture makes more sense than the old one, you can't expect to be compatible with existing apps if you significantly change how the services that were accessed by those APIs work. > It's so frustrating to work alone and become unable to communicate, even > if it lightens the inertia to make great leaps quietly :( agreed. Keith