Spurious triggers
We trigger the script on any udev activity on the network
interfaces. That means we start the script when the interface goes
down as well, which is silly because, well, the network is
down. Fixed: we now fire only on ACTION=="add"
events,
although this still fires quite often... For example, it fires when
the Kobo goes back from the library rescan.
I also noticed that sometimes, turning wifi on did not trigger the
script. (Unconfirmed.)
We could abuse the init system's respawn
flag (as there is
no cron daemon) to fire up the program repeatedly (with a sleep in
between, of course). But this could affect battery usage, so use with
care...
Even worse, the sync gets triggered then the emulated disconnect happens: the nickel environment resumes, reconnects the wifi, and then ... starts the sync again.
It is unclear how to solve this - we don't have many options because the Linux distribution Kobo is running is so ... alien. We could try and hook into DBUS, wpa-supplicant, dhcpcd or some other existing daemon. Finally, the kernel has the netlink(7) socket interface to get notifications for interface changes since Linux 2.2, but that would require starting as a daemon which is trickier.
One trigger we removed is when we have finished reading a book: we
used to just delete it, which would cause yet another trigger. The way
we have worked around this was to simply stop deleting books, but this
puts more burden on the user to manually remove those books... There
is therefore a Delete
option you can add to the JSON configuration
file to enable deletion of read books. I have looked a few commandline
parsers to see if they could start reading from a JSON file:
- cobra - has a configuration file, but it's for command definition, not runtime. interesting project nonetheless and widely used (e.g. Kubernetes, Restic, Hugo, OpenShift...), autocompletion, suggestions, manpage, markdown generation, subcommands, aliases, ...
- kingpin - a bit less obtuse than Cobra, can read commandline from file, manpage generation, type safety, ...
- cli - subcommands, autocompletion, version flag, read defaults from YAML/TOML (and JSON in v2)
- flagconfig does what we need, but requires an incompatible config file format (ini-style)
- docopt.go is a thing, no config file support
- sflags is clever: it maps structs to commandline flags.
I guess that it's impossible to use such a framework and keep our current config file syntax. It may also be impossible to extend the config file without breaking Wallabago, the library. An alternative would be to use environment variables, for example, or just a separate config. We ended up sticking with the default flags parser and just extend our JSON file parsing to support the extra flags, it was simple enough.