Open edorphy opened 1 year ago
@AvdLee thoughts on this one?
The changes I think I would make are the following:
From there, a given app could have their own singleton maintained by the SwiftLog log handler factory. I haven't determined yet if introducing new log levels in Diagnostics would be required or not, but there is presently no output concept of 'level' other than debug and error.
This is sorta related to #141 since allowing the developer to initialize their own DiagnosticLogger would include changing the directory, thus satisfying that constraint.
We would be more than open to add this to the library! We don't have the need ourselves, so it would have to be a public contribution. As long as it's not a breaking change, I believe it makes total sense for added flexibility 🙌
It would be great if DiagnosticLogger was a backing store of SwiftLog's LogHandler. Aside from setup (bootstraping) it would be a true drop-in addition to projects that already make use of other interface logging backing stores.
https://github.com/apple/swift-log
https://github.com/apple/swift-log#on-the-implementation-of-a-logging-backend-a-loghandler
The
DiagnosticLogger
only has two log levels, where SwiftLog and the standard library OSLog / Logger APIs support many more levels. Is conforming as a LogHandler backing store something that would align with the goals of this project?