V2: possible logging approaches

[jwijenbergh]

Two options for logging

• Should we expose a Go function that Logs
  • Pros: Produces uniform logging
  • Cons: Client needs an indirection step to call Go just if it wants to log client specific things
• Should the client register a logging callback/interface? from: @rozmansi Pros: No indirection step for client specific logging Cons: Logging would not be uniform

[jwijenbergh]

from @fkooman: syslog might be nice so a logging callback might be better?

[rozmansi]

One thing is definite: we need to combine logging! There's one log from VPN connection (OpenVPN/WireGuard), one log from eduvpn-common, the eduVPN client for Windows is not even logging to a file but to the OutputDebugString()... Helpdesk is going to kill us if we don't unite this.

1. While OpenVPN and WireGuard already allow tapping into their log, eduvpn-common does not.
2. The client is the glue that holds together eduvpn-common and OpenVPN/WireGuard.
3. Client is platform specific, eduvpn-common is not - on purpose. Log writing is platform specific.

Given all the above, a logging callback letting the client combine log sources and implement the writing to syslog/file/NT EventLog/whatever seems the most reasonable approach.

OTOH, All platforms need logging implemented. Implementing it in eduvpn-common platform-specific internally and offering it as a platform-agnostic API could be the way to "go". Also, less work for me. 😇

So, it all comes down to who will we decide to delegate logging implementation to.