Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature Request: Conform DiagnosticLogger to SwiftLog LogHandler #150

Open
edorphy opened this issue May 29, 2023 · 2 comments
Open

Feature Request: Conform DiagnosticLogger to SwiftLog LogHandler #150

edorphy opened this issue May 29, 2023 · 2 comments
Labels
enhancement New feature or request

Comments

@edorphy
Copy link
Contributor

edorphy commented May 29, 2023

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?

@edorphy
Copy link
Contributor Author

edorphy commented Jun 1, 2023

@AvdLee thoughts on this one?

The changes I think I would make are the following:

  • Change the initializer of DiagnosticLogger to Public
  • Change the access modifier of the shared to Public
  • Make a new static setup function that takes a diagnostic logger and sets it up

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.

@AvdLee
Copy link
Contributor

AvdLee commented Jun 14, 2023

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 🙌

@AvdLee AvdLee added the enhancement New feature or request label Jun 14, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants