That was my idea at first as well and I don't have anything solid to object to about it, other than the extra need for a specification about the domain name entry. Since both solutions are the same in effect, I think "s/" namespace solution is simpler. It's logically separate, easier to parse, etc.khal wrote:d/mydomain/whatyouwant would be used as mysubdomain2.mydomain.bit and used as a part of mysubdomain3.mydomain.bit
We currently know that everything starting with a "d" is a domain. Also, there is no mechanism to prevent other people from registering "d/yourname/theirname" and although this is not a problem, it reduces the actual usefulness of the spec. We'd be better off reserving the name spec for other purposes, such as alternative TLDs. (I got the "s/" idea from vinced, maybe he has a more authoritative opinion about this issue, since I'm almost impartial.)
You can't create hierarchies with "merge". It is there only to extend storage space. I put it there, but I still don't like it.khal wrote:Do we really need both sub + merge ? Only merge wouldn't be sufficient ?
EDIT: After re-reading your post, looks to me like we can use "merge" to do more than just increase storage.
The reason we have this proposal is to allow delegation of sub-domains to different people, like DNS, so the waste of domain is actually the purpose. How big a concern is this?khal wrote:Creating domain names like "d/mydomain2/blabla" is a waste of a domain. Instead, the "merge":"d/mydomain2/blabla" could simply look at "d/mydomain2" and take that config of the subdomain "blabla". But, in that case, blabla.mydomain2.bit would exists too and we may not want that.
Plus, what you say should be possible with "translate" and "alias" directives, no?
It's exactly designed for that.khal wrote:The second choice will create a problem with sub-sub domains because it could be interpreted as merged.whatyouwant.mydomain2.bit. This last sentence lead me the a question : the spec is not designed for sub-sub domains ?
EDIT: Here is something idiotic that you can do with "sub", which could serve as an explanation about how sub-sub-domains could work:
s/sillysub:
Code: Select all
{ "map": { "" : "10.0.0.2", "y": { "sub": "d/sillydom" } } }
Code: Select all
{ "map": { "" : "10.0.0.1", "x": { "sub": "s/sillysub" } } }
Hmm, this also raises questions about implementation difficulties of course. (Recursion would need to be done on the fly.)