Proposal: standard logging facility


(Alexander Kolov) #1

Hi everyone,

Coming from a short discussion in swift-corelibs-dev, I’m investigating the need of a standard logging API as a part of core libraries.

The motivation behind this would be having a unified and configurable set of APIs between all first-party modules and third party applications and libraries.
I think this will help each of us since right now we’re inventing our own solutions as well many bigger third-party library providers have formats and facilities of their own.

As I currently see it would be somewhat similar to python logging and possibly even structlog (http://www.structlog.org/en/stable/), with configurable formatters and handlers, including and not limited to remote loggers and syslog support.

I’d love to hear your opinions and feedback on this and possibly start with some more formalized proposal and implementation if there’s enough support and need.

Thanks,
Alex


(David Waite) #2

I would propose the simplest interface that I can assume is available *everywhere* to be defined by the Swift standard library, so as a framework developer I can make assumptions on my ability to provide diagnostics for internals, expose information for statistical use, provide information needed for auditing usage if I’m working on a hosted service and not a GUI app, and so on.

Things like custom formatters and appenders providing integration into remote/system services are something that the application can decide when it chooses a logging framework that implements the standard-defined protocol.

There isn’t any sort of dependency injection/inversion of control at the core swift level, which usually means that either logging is done by global functions, or by a global factory returns an instance of some type implementing the logging protocol.

The only piece of this which jumps out as not pure swift would be default integration into something like syslog or NSLog, and possibly adding a new preprocessor “macro” like __MODULE__

-DW

···

On Dec 5, 2015, at 1:20 PM, Kevin Barrett via swift-evolution <swift-evolution@swift.org> wrote:

+1 to this.

On Sat, Dec 5, 2015 at 2:24 PM, Alexander Kolov via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
Hi everyone,

Coming from a short discussion in swift-corelibs-dev, I’m investigating the need of a standard logging API as a part of core libraries.

The motivation behind this would be having a unified and configurable set of APIs between all first-party modules and third party applications and libraries.
I think this will help each of us since right now we’re inventing our own solutions as well many bigger third-party library providers have formats and facilities of their own.

As I currently see it would be somewhat similar to python logging and possibly even structlog (http://www.structlog.org/en/stable/), with configurable formatters and handlers, including and not limited to remote loggers and syslog support.

I’d love to hear your opinions and feedback on this and possibly start with some more formalized proposal and implementation if there’s enough support and need.

Thanks,
Alex

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Kevin Barrett) #3

+1 to this.

···

On Sat, Dec 5, 2015 at 2:24 PM, Alexander Kolov via swift-evolution < swift-evolution@swift.org> wrote:

Hi everyone,

Coming from a short discussion in swift-corelibs-dev, I’m investigating
the need of a standard logging API as a part of core libraries.

The motivation behind this would be having a unified and configurable set
of APIs between all first-party modules and third party applications and
libraries.
I think this will help each of us since right now we’re inventing our own
solutions as well many bigger third-party library providers have formats
and facilities of their own.

As I currently see it would be somewhat similar to python logging and
possibly even structlog (http://www.structlog.org/en/stable/), with
configurable formatters and handlers, including and not limited to remote
loggers and syslog support.

I’d love to hear your opinions and feedback on this and possibly start
with some more formalized proposal and implementation if there’s enough
support and need.

Thanks,
Alex

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Ling Wang) #4

+1. I filed a radar about it months ago.

···

On Dec 5, 2015, at 1:24 PM, Alexander Kolov via swift-evolution <swift-evolution@swift.org> wrote:

Hi everyone,

Coming from a short discussion in swift-corelibs-dev, I’m investigating the need of a standard logging API as a part of core libraries.

The motivation behind this would be having a unified and configurable set of APIs between all first-party modules and third party applications and libraries.
I think this will help each of us since right now we’re inventing our own solutions as well many bigger third-party library providers have formats and facilities of their own.

As I currently see it would be somewhat similar to python logging and possibly even structlog (http://www.structlog.org/en/stable/), with configurable formatters and handlers, including and not limited to remote loggers and syslog support.

I’d love to hear your opinions and feedback on this and possibly start with some more formalized proposal and implementation if there’s enough support and need.

Thanks,
Alex

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Alexander Kolov) #5

I agree we need as minimal interface in the core library as possible while allowing application to take over whole logging configuration process.
Specific formatters, handlers and such will have to be implemented as external packages of course.

···

Sent from my iPhone

On Dec 5, 2015, at 10:05 PM, David Waite <david@alkaline-solutions.com> wrote:

I would propose the simplest interface that I can assume is available *everywhere* to be defined by the Swift standard library, so as a framework developer I can make assumptions on my ability to provide diagnostics for internals, expose information for statistical use, provide information needed for auditing usage if I’m working on a hosted service and not a GUI app, and so on.

Things like custom formatters and appenders providing integration into remote/system services are something that the application can decide when it chooses a logging framework that implements the standard-defined protocol.

There isn’t any sort of dependency injection/inversion of control at the core swift level, which usually means that either logging is done by global functions, or by a global factory returns an instance of some type implementing the logging protocol.

The only piece of this which jumps out as not pure swift would be default integration into something like syslog or NSLog, and possibly adding a new preprocessor “macro” like __MODULE__

-DW

On Dec 5, 2015, at 1:20 PM, Kevin Barrett via swift-evolution <swift-evolution@swift.org> wrote:

+1 to this.

On Sat, Dec 5, 2015 at 2:24 PM, Alexander Kolov via swift-evolution <swift-evolution@swift.org> wrote:

Hi everyone,

Coming from a short discussion in swift-corelibs-dev, I’m investigating the need of a standard logging API as a part of core libraries.

The motivation behind this would be having a unified and configurable set of APIs between all first-party modules and third party applications and libraries.
I think this will help each of us since right now we’re inventing our own solutions as well many bigger third-party library providers have formats and facilities of their own.

As I currently see it would be somewhat similar to python logging and possibly even structlog (http://www.structlog.org/en/stable/), with configurable formatters and handlers, including and not limited to remote loggers and syslog support.

I’d love to hear your opinions and feedback on this and possibly start with some more formalized proposal and implementation if there’s enough support and need.

Thanks,
Alex

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Chris Lattner) #6

Hi Alex,

At this point, we’d prefer that major new features like these be explored and developed as independent projects outside the official Swift repos. There are a *ton* of really interesting library features that we could add, but for now at least, we’re keeping the Swift standard library laser focused on its “language features + core data structures & algorithms” focus, and keeping the CoreLibs work focused on achieving parity with the Apple implementations of these libraries.

We simply don’t have bandwidth to review and design higher level features at this time. One of the goals of the Swift package manager is to make it super easy to reuse people’s code, even if it isn’t part of the swift distro.

-Chris

···

On Dec 5, 2015, at 11:24 AM, Alexander Kolov via swift-evolution <swift-evolution@swift.org> wrote:

Hi everyone,

Coming from a short discussion in swift-corelibs-dev, I’m investigating the need of a standard logging API as a part of core libraries.

The motivation behind this would be having a unified and configurable set of APIs between all first-party modules and third party applications and libraries.
I think this will help each of us since right now we’re inventing our own solutions as well many bigger third-party library providers have formats and facilities of their own.

As I currently see it would be somewhat similar to python logging and possibly even structlog (http://www.structlog.org/en/stable/), with configurable formatters and handlers, including and not limited to remote loggers and syslog support.

I’d love to hear your opinions and feedback on this and possibly start with some more formalized proposal and implementation if there’s enough support and need.


(Roshan) #7

I have used Lumberjack[1] with Objective-C and I found it pretty good.
Maybe it's scope is too large for the standard library, but it could serve
as a good reference.

[1] - https://github.com/CocoaLumberjack/CocoaLumberjack

···

On Sun, Dec 6, 2015 at 12:54 AM, Alexander Kolov via swift-evolution < swift-evolution@swift.org> wrote:

Hi everyone,

Coming from a short discussion in swift-corelibs-dev, I’m investigating
the need of a standard logging API as a part of core libraries.

The motivation behind this would be having a unified and configurable set
of APIs between all first-party modules and third party applications and
libraries.
I think this will help each of us since right now we’re inventing our own
solutions as well many bigger third-party library providers have formats
and facilities of their own.

As I currently see it would be somewhat similar to python logging and
possibly even structlog (http://www.structlog.org/en/stable/), with
configurable formatters and handlers, including and not limited to remote
loggers and syslog support.

I’d love to hear your opinions and feedback on this and possibly start
with some more formalized proposal and implementation if there’s enough
support and need.

Thanks,
Alex

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

--
Warm regards
Roshan


(Alexander Kolov) #8

Yes, we could definitely use it as a reference of use cases and requirements.
For the standard library we'd need fast extensible solution upon which anyone can build their own handlers.

···

Sent from my iPhone

On Dec 5, 2015, at 9:16 PM, Roshan <thisisroshansmail@gmail.com> wrote:

I have used Lumberjack[1] with Objective-C and I found it pretty good. Maybe it's scope is too large for the standard library, but it could serve as a good reference.

[1] - https://github.com/CocoaLumberjack/CocoaLumberjack

On Sun, Dec 6, 2015 at 12:54 AM, Alexander Kolov via swift-evolution <swift-evolution@swift.org> wrote:
Hi everyone,

Coming from a short discussion in swift-corelibs-dev, I’m investigating the need of a standard logging API as a part of core libraries.

The motivation behind this would be having a unified and configurable set of APIs between all first-party modules and third party applications and libraries.
I think this will help each of us since right now we’re inventing our own solutions as well many bigger third-party library providers have formats and facilities of their own.

As I currently see it would be somewhat similar to python logging and possibly even structlog (http://www.structlog.org/en/stable/), with configurable formatters and handlers, including and not limited to remote loggers and syslog support.

I’d love to hear your opinions and feedback on this and possibly start with some more formalized proposal and implementation if there’s enough support and need.

Thanks,
Alex

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

--
Warm regards
Roshan


(Alexander Kolov) #9

Thank you for the input, Chris!

I'll do my best to kickstart this project with the spirit of the core library standards and distributive it with package manager. Then maybe we could revisit closer dependency at some later date.

PS. If anyone is interested in participating, please feel free to contact me directly.

Alex

···

Sent from my iPhone

On Dec 6, 2015, at 7:20 AM, Chris Lattner <clattner@apple.com> wrote:

On Dec 5, 2015, at 11:24 AM, Alexander Kolov via swift-evolution <swift-evolution@swift.org> wrote:

Hi everyone,

Coming from a short discussion in swift-corelibs-dev, I’m investigating the need of a standard logging API as a part of core libraries.

The motivation behind this would be having a unified and configurable set of APIs between all first-party modules and third party applications and libraries.
I think this will help each of us since right now we’re inventing our own solutions as well many bigger third-party library providers have formats and facilities of their own.

As I currently see it would be somewhat similar to python logging and possibly even structlog (http://www.structlog.org/en/stable/), with configurable formatters and handlers, including and not limited to remote loggers and syslog support.

I’d love to hear your opinions and feedback on this and possibly start with some more formalized proposal and implementation if there’s enough support and need.

Hi Alex,

At this point, we’d prefer that major new features like these be explored and developed as independent projects outside the official Swift repos. There are a *ton* of really interesting library features that we could add, but for now at least, we’re keeping the Swift standard library laser focused on its “language features + core data structures & algorithms” focus, and keeping the CoreLibs work focused on achieving parity with the Apple implementations of these libraries.

We simply don’t have bandwidth to review and design higher level features at this time. One of the goals of the Swift package manager is to make it super easy to reuse people’s code, even if it isn’t part of the swift distro.

-Chris