Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature request: rename host -> owner #625

Open
2 tasks
qdm12 opened this issue Feb 3, 2024 · 7 comments
Open
2 tasks

Feature request: rename host -> owner #625

qdm12 opened this issue Feb 3, 2024 · 7 comments
Labels

Comments

@qdm12
Copy link
Owner

qdm12 commented Feb 3, 2024

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
@qdm12 qdm12 added Status: 🔒 After next release Will be done after the next release Complexity: 🟩 Easy to do Category: Documentation ✒️ A problem with the readme or in the docs/ directory Category: Foolproof settings 👼 labels Feb 3, 2024
@qdm12 qdm12 mentioned this issue Feb 3, 2024
@Peronia
Copy link

Peronia commented Feb 16, 2024

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
Copy link
Owner Author

qdm12 commented Feb 19, 2024

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
Copy link

Peronia commented Feb 20, 2024

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
Copy link
Owner Author

qdm12 commented Feb 29, 2024

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
Copy link

Peronia commented Mar 4, 2024

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
Copy link
Owner Author

qdm12 commented Mar 7, 2024

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
Copy link

Peronia commented Mar 10, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants