Feature request: rename `host` -> `owner`

[qdm12]

The current parameter host is a computer name in a network and is not a perfect name, despite being used by a few providers on their Web UI. subdomain is problematic/misleading since for example a.b.c.com is a subdomain of b.c.com, despite the domain being c.com; plus @ or * are not really subdomains. The technical DNS name for this left part for a certain domain is owner, and we should use it to avoid confusion.

• Rename JSON parameter in all docs/ documents
• Rename with retro-compatibility the JSON field host in the code

[Peronia]

Well, I think owner is not really better than host. I agree with you, host have nothing todo with this parameter. But in my view owner is very technically. In my case I have a lot of confusion even when I found that issue, see here.
I would suggest a name like prefix/domainprefix or subpart. Yeah I know this terms are not 100% correct, but my case is about understanding. And I agree also with you that subdomain can be misleading.
I could add a part at the readme that add more explanation, when you want I can open a PR.

[qdm12]

Why not otherwise have domain accept forms such as *.domain.com, domain.com and abc.domain.com, and remove (keep it for retro compat) the host field? 🤔

[Peronia]

Well, thats the best way of understanding. But is this technically possible? I know you are the maintainer so you don't suggest things that won't work I think. Do we need this host/owner value as a seperate info?

[qdm12]

In general, domains are of the form domain.tld. It's possible maybe to have do.main.tld but it's rather uncommon. If one uses such form, he/she can set the owner in the old (kept for retro-compatibility) "host" field to make sure ddns-updater understands do.main.tld is the domain and not main.tld. Not something I want to document unless someone raises an issue about this, since I have never seen such case. So in general it will be s.u.bdomain.domain.tld and ddns-updater will understand s.u.bdomain as the owner and domain.tld as the domain.

Overall I think what's needed:

1. commit 1: add an owner field to mimic the host field, and replace host with owner in the documentation. Just plain bad naming that needs to go away. Add a note to remove the host field in a future breaking changes v3 release. We may want to keep the owner field for weird edge cases where the (dns technical sense) domain has more than 1 dot.
2. commit 2:
   • if owner/host is set, use it as the owner and use the domain value as.. the domain (in the dns technical terminology sense)
   • if owner/host is not set, get the owner and domain from the domain field of the form optional.domain.com. The owner can be empty (-> @) if the domain is just domain.com.
   • remove any documentation on the owner field
   • update documentation on the domain field
   • pay attention to special cases duckdns.org and goip.de not having a domain really but only an owner configurable, but that should fit fine with the above.

So in the end, we would just have the "domain" field, except for the weird domain names where "owner" may come into play, but we keep it secret 😄

[Peronia]

Okay, got it. But why remove the documentation? Then we have an undocumentated field, that is not very nice. I would suggest to move the documentation to another plac, like archive or something like that.

[qdm12]

Because the code would still be functional with the older host field, and I hope we wouldn't need it going forward. Older documentation can still be accessed by accessing release tagged trees on github (or specific commits). If people already using the program can migrate to the newer format, that's also better for a smoother migration to a v3 release 😉

[Peronia]

I'm still not convinced about having an undocumented field, but it's not my project, I would solve it differently.
The github tree thing sounds more complicated, I'm not familiar with it anyway.

[qdm12]

1. 55d8c0d added versioned readme+docs/ links to the readme
2. 32fafec host renamed to owner in documentation, code, and config.json. This is retro-compatible with the JSON host field key still.
3. 07d7645 both host and owner removed in favor of getting the owner and "eTLD+1" from the domain field value, using golang.org/x/net/publicsuffix and a bit of string manipulation logic. This is still retro-compatible with both the host and owner JSON config field keys, which takes precedence if set to a non empty string.

Closing this since all these points should resolve this 😉