search

namecoin / proposals

Standards and Best Practices
Creative Commons Zero v1.0 Universal
12 stars 5 forks source link

Get Daniel's feedback on import #4

Open JeremyRand opened 9 years ago

JeremyRand commented 9 years ago

I'd like to get Daniel's feedback on import before finalizing the d/ spec.

(moved from https://github.com/hlandau/ncdocs/issues/13 )

JeremyRand commented 9 years ago

Hello @domob1812, any chance we can get your feedback on the "import" syntax used in this spec? It's different from the syntax you implemented in NMControl, and indirectly affects id/ (because it establishes that "import" has different semantics per namespace).

domob1812 commented 9 years ago

I've only looked briefly at the proposal. The main "difference" I see is that (as you wrote) "import" is defined somewhat in a d/-specific way. In particular, the subdomain selectors are not present in what I implemented for NMControl. I did not really spot any other major differences. Are there any?

To be honest, I would still prefer to define "import" as a generic thing not specific to d/ at all. Is there a strong reason why "import" needs to be specific to d/ and in particular, why we need the subdomain selectors? As I understand it, the main problem with the current spec is that it "overrides" a subdomain named "import". Couldn't we rename the field to a name unlikely to clash with a subdomain and go without special rules?

Of course, maybe usage of "import" should not be generally demanded by processors of any namespace. But I would like to have it defined generically so that the d/ spec (and any other spec of a namespace) would then simply state that "imports should be processed according to spec XYZ".

hlandau commented 9 years ago

As I've previously discussed with @JeremyRand, import should not be implemented in a generic fashion.

Please search for "generic import" on this page, it appears several times: https://forum.namecoin.info/viewtopic.php?f=5&t=1294&start=10

domob1812 commented 9 years ago

@hlandau: Ok, so you say that a "generic JSON" import is not what we want for d/. This may be true - however, I have to admit, that I did not see any rules in the proposed spec that actually are d/ specific. The spec read to me like a generic JSON import very similar to what we already have in NMControl (although not 100%). Is this understanding wrong? (I only read it very quickly as I'm currently traveling.) If so, please point those details out.

My understanding is that the spec, as it is, could more or less be used also for id/ (just removing the subdomain selectors). And if that is the case, I would rather have something like "import MUST be processed according to GENERIC IMPORT SPEC" in the id/ proposal instead of "import MUST be processed as specified in the d/ spec, without the subdomain selectors". But if the d/ spec has specific definitions that do not make sense for id/, I understand that it makes sense to specify import for each namespace separately. I just did not see any.

What comments do @phelixBTC and @cassiniNMC have?

JeremyRand commented 9 years ago

So, I think there are at least two issues here.

First, the issue of a "import" subdomain. I think it might be workable to define "import" in a way that it is only processed in certain contexts, but has namespace-neutral semantics when it is processed. E.g. d/ could say that "import" does not get processed when it's a child of "map"

Second, the issue of the subdomain selector being d/-specific. I think it might be okay to make the subdomain selctor use a JSON path rather than a domain path. So it would have to specify the "map" in the path, but would be applicable to most other JSON-based namespaces. I think it does make sense for id/ to have a subdomain selector of some kind.

Thoughts?