LoggingAPI
pion-WebRTC currently uses fmt.Println sprinkled through out the code base. For the most grievous errors we always print them, for warnings we usually comment them out (and then developers re-enable them locally)
This is a frustrating way to work for developers, and doesn't work at all for users. Developers just add fmt.Println messages throughout the code base. Users have it even worse, when they have an issue they don't know where to go next to debug their issue. We also have bug reports where a user just sees a message, but not sure what is happening. It turns out the message is informational and we debug.
- Give pion-WebRTC maintainers a quicker way to debug/trace, without having to edit existing code
- Allow pion-WebRTC embedders to capture logs, and store them in format that matches existing system (JSON etc...)
- Allow logging on different levels/components (Trace+ICE) (Warning+SDP)
I am hesitant to import an existing logging solution. It would be nice if we didn't import any non-Pion libraries, I would like to allow embedders to choose anything they want, and not steer them in a certain way.
Also it is nice that we aren't dependent on other people making changes we don't agree with/having to track other projects development. It seems like a lot of Open Source projects that just use a bunch of libraries fall into a trap of having to just follow everyone's release schedule.
From mjmac:
Does it make sense to provide a traditional leveled logging facility for a library? What does it mean to log a warning or error? If it's an error, then it should either be handled or returned to the user code. If it's not an error, then it's not actionable, so in the long run it's just spam. Along those lines, then, what is the purpose in logging things at Info or Notice levels?
In my opinion, libraries shouldn't be emitting any log output by default -- that's for user code to deal with. That having been said, being able to turn on trace/debug logging while developing or debugging is very helpful. I'm not sure that it's necessary to allow users to be able to feed that into their own logging configuration, though. Output to stdout works fine and can be grep-ed for customization.
To summarize, I'm leaning toward a minimal solution that allows developers to log by subsystem, and logging for a given subsystem is either all-on or all-off (i.e. no levels). If folks think that having a trace/debug distinction would be useful I'm open to the idea, but I wonder if it would be used in practice. I tend to want all the logs when I'm debugging, because it's annoying to only get half of the logs and then try to reproduce with extra logging enabled.
Sign up for the Golang Slack and join the #pion channel for discussions and support
If you need commercial support/don't want to use public methods you can contact us at team@pion.ly