6 ms·

> Hierarchically organized is not a hard requirement Technically correct, but in practical use, it is absolutely a requirement. Entities within domains are usu

> Hierarchically organized is not a hard requirement Technically correct, but in practical use, it is absolutely a requirement. Entities within domains are usually hierarchically organized, this already starts at the top level by having www.domain, mail.domain, dns.domain, file.domain, ... So if we implemented a scheme without built-in hierarchy, I can 100% guarantee that one of the first things admins will do, is implement their own hierarchy naming conventions on top of it, just to keep things organized. The difference then is, that we won't have one clear way to do that, but hundreds of different ones. > I don't think routing would actually be an issue though, given the power of today's servers Anything that relies on "worse solution offset by throwing more compute at it", is an instant "denied" in my book. That's how we ended up with electron apps.

samatman 3y ago
You're greatly overstating the performance requirements here, DNS could just hash the string and farm out to 256 subservers running subsidiary hashmaps to the associated IP address. The multi-level schema is absolutely not a performance requirement, comparing this to Electron is silly, it is in fact much simpler than the DNS we have, with comparable demands in terms of memory and compute. We agree about the utility of heirarchy in domains on a social and administrative level, though.
- usrbinbash 3y ago
  > You're greatly overstating the performance requirements here No I'm really not, I am simply saying that doing something in a way that requires way more compute for the same result, without ANY tangible advantage over the existing system, is a bad solution. It doesn't matter if its doable.