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