[Feedback] Server Logging API (with revisions)

Server Proposals
101

The intention was just that a LogHandler can use the label if it chooses too. But I agree we could have a property to be able to read the label back on Logger which would take it from a to-be-created property on LogHandler.

102

I created a Pull Request to add a label property on LogHandler similar to DispatchQueue.

I am not sure though if it makes more sense in the context of logging to make this property non-optional.

1 Like
103

Would you provide an example use case for this label property? In general wouldn't the owner of a logger already know the label which was used to create the logger (since the owner would have provided the label to the factory)?

104

I guess it can be useful in debugging for example (just like with dispatch queues).
I have used it to designate the subsystem where I create the logger (e.g. let logger Logger(label: "com.app.apiclient")) but I understand that this could also be handled with metadata.

My main point was that since the framework clearly has a notion of labels in the Logging API, there should be a way to read it back out.

105

Just to give an update here that the official repo is on track and we'll open that very soon which will then open the development of the OSS project. I'll post another link here very soon.

One other thing that I should have posted here is that there's a separate discussion about the log levels for os_log and this logging API going on in the forums. The logging API will adopt the outcome of that, it very much looks like it'll be the syslog log levels.

4 Likes
106

First of all: Sorry for the delay!

After the SSWG accepted this proposal to the 'sandbox' stage, we finally followed through and opened the repository :slight_smile:. So we can now officially kick off the open-source swift-log project!

The swift-log repository got seeded from the pitch/proposal repository which was under my personal github alongside a few changes:

  • adoption of the log levels as discussed in the separate thread
  • name: swift-log
  • proper licensing (Apache 2, as proposed)
  • rename the Logging type to LoggingSystem so we don't have a clash between the module name (Logging) and the type to bootstrap your loggers
  • added a readme and some API docs
  • removed the proposal/examples
  • just like proposed for osLog, to leverage the best performance and have more unification we switched the log messages' type from String to Logger.Message which is a struct that can be created using any string literal + string interpolation. Don't worry, it looks & feels just like a String (logger.info("hello world"))
  • require Swift 5 (required for the new string interpolation support)
  • a bunch of smaller changes

Thank you so much for all the contributions! Now more than ever: please keep your awesome contributions coming, this is only the start of swift-log and swift-log is only the start of a logging that works across the whole ecosystem.

9 Likes