Regression in provider naming

[Tsuroerusu]

In the provider list shown in the man page for inadyn.conf, the following is shown for dynv6:

           default@dynv6.com
                 ⟨https://dynv6.com⟩
           default@ipv4.dynv6.com
                 ⟨https://ipv4.dynv6.com⟩

However in the source file for the dynvy plugin (dynv6.c), the provider names are defined as follows:

static ddns_system_t plugin4 = {
	.name         = "default@ipv4.dynv6.com",
...
static ddns_system_t plugin6 = {
	.name         = "ipv6@dynv6.com",

This causes inadyn to fail to start if a user read the man page and used the provider name "default@dynv6.com" because it literally does not exist as far as the source code is concerned.

This change was introduced in 8129243 , and just from a purely text aesthetic view seems rather like a pretty strange change to make unless "default@dynv6.com" was then added as an alias for "ipv6@dynv6.com" since it literally breaks users' configurations.

Perhaps the IPv6 provider ought to be "default@ipv6.dynv6.com" (Which should work according to the dynv6 documentation: https://dynv6.com/docs/apis#update ) and then the man page could be changed to reflect this, so it showed the following:

           default@ipv6.dynv6.com
                 ⟨https://ipv6.dynv6.com⟩
           default@ipv4.dynv6.com
                 ⟨https://ipv4.dynv6.com⟩

To make sure existing configurations kept working, perhaps "default@dynv6.com" should then be an alias for the IPv4 provider as, I think, one could reasoanbly assume that IPv4 is the most commonly used one.

[troglobit]

Yeah, we had a huge influx of support for new providers, including a revamp of the ipv6 support, from the DD-WRT project. We have not had the time to update the documentation accordingly.

There is however a little help, a new command inadyn --list-providers that we will likely try to include as a some direction in the help when we get to it.

[Tsuroerusu]

Yeah, we had a huge influx of support for new providers, including a revamp of the ipv6 support, from the DD-WRT project. We have not had the time to update the documentation accordingly.

There is however a little help, a new command inadyn --list-providers that we will likely try to include as a some direction in the help when we get to it.

That is, of course, completely understandable and thanks for that command tip, that does show the correct provider names. I would still respectfully suggest, that a somewhat more consistent naming of the providers would be helpful, but, as I said, I completely understand being overwhelmed with other issues. Thanks for your efforts, inadyn is a very useful tool.

[troglobit]

Naming things is hard. We cannot rename existing providers, because that would break setups for users upgrading. This is an old project … eons of sediment on top of sediments …

…

On Sat, 22 Jul 2023 at 12:01, Troels Just ***@***.***> wrote: That is, of course, completely understandable and thanks for that command tip, that does show the correct provider names. I would still respectfully suggest, that a somewhat more consistent naming of the providers would be helpful, but, as I said, I completely understand being overwhelmed with other issues. Thanks for your efforts, inadyn is a very useful tool. — Reply to this email directly, view it on GitHub <#434 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABMZXNWHMCHVFIDTNW574LXROQGVANCNFSM6AAAAAA2TNTT6U> . You are receiving this because you commented.Message ID: ***@***.***>

[Tsuroerusu]

Naming things is hard. We cannot rename existing providers, because that would break setups for users upgrading. This is an old project … eons of sediment on top of sediments …

Of course, I guess what I was trying to say, and I apologize for being unclear, was that, that is literally the issue here. The provider name "default@dynv6.com" used to work and now it does not, because there is no "default" for the domain "dynv6.com", it is either "ipv6" or default for the subdomain "ipv4.dynv6.com". That seems like a regression to me.

[troglobit]

You’re right, that’s definitely another regression. Thanks for clarifying. I’ll go through it all again for the next patch release

…

On Sat, 22 Jul 2023 at 12:12, Troels Just ***@***.***> wrote: Naming things is hard. We cannot rename existing providers, because that would break setups for users upgrading. This is an old project … eons of sediment on top of sediments … … <#m_403727145091931050_> On Sat, 22 Jul 2023 at 12:01, Troels Just *@*.*> wrote: That is, of course, completely understandable and thanks for that command tip, that does show the correct provider names. I would still respectfully suggest, that a somewhat more consistent naming of the providers would be helpful, but, as I said, I completely understand being overwhelmed with other issues. Thanks for your efforts, inadyn is a very useful tool. — Reply to this email directly, view it on GitHub <#434 (comment) <#434 (comment)>>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABMZXNWHMCHVFIDTNW574LXROQGVANCNFSM6AAAAAA2TNTT6U <https://github.com/notifications/unsubscribe-auth/AABMZXNWHMCHVFIDTNW574LXROQGVANCNFSM6AAAAAA2TNTT6U> . You are receiving this because you commented.Message ID: @.*> Of course, I guess what I was trying to say, and I apologize for being unclear, was that, that is literally the issue here. The provider name " ***@***.***" used to work and now it does not, because there is no "default" for the domain "dynv6.com", it is either "ipv6" or default for the subdomain "ipv4.dynv6.com". That seems like a regression to me. — Reply to this email directly, view it on GitHub <#434 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABMZXO5LEUY7SLW4HCDQSTXRORQXANCNFSM6AAAAAA2TNTT6U> . You are receiving this because you commented.Message ID: ***@***.***>

[troglobit]

Note to self: need to add an alias handling to wrap all the regression introduced in v2.11.0