Future architecture of ddclient

[LenardHess]

This issue is meant as an overview of future changes we (the maintainers) are thinking about doing.

Anything in here is up for discussion, please comment!

---

General goals & design philosophy

1. Break up the big monolithic ddclient perl script into more maintainable chunks.
2. Cleanly separate provider-specific, router-specific or any other special case logic from the generic workings of ddclient.
3. Provide a clear, gradual upgrade path. I consider ddclient's main value to be its age - it has been around for a long time and hence been used for a long time. Moving fast and breaking things would erode that foundation.

Future possible steps

Overview

• Move the IP acquisition methods into scripts
• Separate provider implementations from core logic
• Add hook scripts to various stages of the update process
• Move sendmail support to external script
• Rewrite in a more modern language

Move the IP acquisition methods into scripts

Status quo

We have arrays containing URLs plus text matching patterns (here and here)
We also have a sample script for IP acquisition here.

Future strategy

I would consider the sample script approach to be the path forward. This decouples the semantics on how to acquire an IP from the core ddclient logic through a very clearly defined boundary (a script call).

For example, we could have scripts/IP/ipv4_web_dyndns.sh for retrieving an IPv4 address from http://checkip.dyndns.org
(Exact folder structure, script naming etc. to be determined).
Then we can also have template scripts for users to create their own easily.

Backwards compatibility

For backwards compatibility this can be hooked up in a way where the legacy configuration maps to the scripts (i.e. a
usev4=web, web=[my_ip_discoverer] would try and use the scripts/IP/ipv4_[my_ip_discoverer].sh script.

Open questions and miscellaneous thoughts

How to handle scripts requiring secrets like login passwords? Should we let scripts figure that out themselves or provide a clean solution on how ddclient takes in the secrets from the config and passes it onto the script(s)? My gut feeling says we should have some mechanism in place to encourage doing the right thing in scripts (no hardcoding secrets etc.)

What should the script interface look like? The obvious approach would be calling a script with no parameters and the IP to be printed to stdout by the script. Log/Error messages can go to stderr, success/fail to the exit code. No matter what, when/if we build this, have this definition in place first!

Separate provider implementations from core logic

As of right now, over half (>4k out of 7.8k lines) of the ddclient script are just the provider implementations.
I want to separate the providers from the main logic. For that I see multiple approaches:

• Move all providers into a separate perl file (module?).
• Move each provider into a separate perl file.
• Define an interface (script call?) with which providers are implemented. Move the providers behind that interface.

Add hook scripts to various stages of the update process

There's various things we should be able to trivially allow:

• Checking an IP for validity (i.e. not a local IP)
• Reporting success/error
• Running tasks after an update
  All of those should be easily doable by letting users add scripts to be called for various events.

There is already support for running a script after an update (postscript config key), but its not well documented.

Move sendmail support to external script

The sendmail support for sending success/fail messages falls under the general reporting of success/fail mentioned above.
Moving to an example script allows us to maintain backwards compatibility while also allowing other notification channels like push notification services.

Rewrite in a more modern language

Let me preface this with - I am not considering this to be an option in the near future.

Status quo

Multiple people have voiced their reservations with the legacy of ddclient being written in perl (here, here).
I too am not enjoying the fact that we're writing perl here 😉

The main ddclient script is ~4k lines of perl for general logic and the provider implementations each - just shy of 8k lines total.
The surrounding example scripts are simple shell scripts.

Other language candidates

To me, the first candidate for an alternative language would be python. It should be just as readily available as perl on most distributions.

A path to a new language

To adopt a new language, the following prerequisites exist in my opinion:

• Get downstream maintainers' input on language availability.
• Have clearly defined semantics of anything that gets rewritten and have tests in place to verify them.
• Have a rewriting strategy in place on what gets rewritten when. I do not have the time to write or review a full rewrite at once.

This, to me, leaves the following path forward open - should we decide to start moving away from perl:

1. We define the interfaces for the various script calls mentioned in the other points above (IP acquisition, provider updates
   etc.)
2. We (re)write first parts of the external scripts in $newlanguage (i.e. a provider implementation), offering a legacy perl implementation at the same time
3. We start out via opt-in to get first active testing coverage in the field.
4. We iron out any first issues found that way (i.e. downstream package build system updates).
5. We transition to use $newlanguage by default for the rewritten parts.
6. We iron out any further issues found by users.
7. We drop legacy perl support for rewritten parts
8. We continue rewriting until done.

[rhansen]

Other language candidates

To me, the first candidate for an alternative language would be python. It should be just as readily available as perl on most distributions.

One of the big downsides of Perl is the difficulty in using 3rd party modules due to varying distribution support (e.g., a library might not be packaged, or might be too old). While Python is a nicer language (IMO), it doesn't solve that problem.

Also, ideally ddclient would be runnable on small devices such as home WiFi routers. An interpreter and support libraries are problematic due to the limited resources. Switching to Python wouldn't help here either.

My preference would be to use a modern compiled language that allows us to (1) avoid dependency hell, and (2) minimize footprint. As a bonus, we could produce a shared library that Perl can directly call into, making it easier to gradually migrate code.

For potential candidates, Go and Rust come to mind. I don't have any experience with Rust so I can't opine on its suitability, but I have written lots of Go code:

• Pro: Go statically links everything, so dependency availability on the target platform is not an issue. This makes it easy to use whatever 3rd party library you want.
• Pro: Static linking also means the resulting binary is free of references to shared libraries, making it trivial to install on any compatible system.
• Con: I'm not convinced they have a reasonable story for vulnerability management: If a library has a vulnerability, all projects that use that library have to be rebuilt.
• Con: Last time I looked the compiler did not support a wide array of devices, making it less portable to various home routers.
• Con: It is primarily backed by Google, which is notorious for abandoning projects.
• Con: The more I use it the more frustrated I get by the language's idiosyncrasies.