Add structured support to kv::Value using sval #342

Merged

KodrAus merged 3 commits from feat/sval-values into master

2019-07-24 16:17:08 -05:00

KodrAus commented

2019-07-16 00:02:14 -05:00

(Migrated from github.com)

What's this all about?

This PR adds a new unstable feature for structured logging that lets consumers actually interact with the structure of values.

It doesn't do this by exposing its own serialization contract. Instead, it implements traits from a serialization framework called sval. I'm open to any philosophical debate on different approaches here!

There are two commits that I think demonstrate how it fits together:

Refactor value internals so we can add in-band serialization frameworks easily.
Add sval support. This is the one to look at if you're interested in what impact introducing in-band frameworks has.

What is `sval`?

sval is a serialization-only framework I've been working on specifically for use in log. sval supports no-std, object-safe serialization for primitives and more complex structures like maps and sequences. It absolves log from having to produce and maintain its own serialization contract, so it can stay focused, but lets it provide a complete serialization API for consumers.

What about `serde`?

serde is the other serialization framework I've been planning to support in-band in log because it's ubiquitous (and does its job very well). I haven't started with it because:

It'll require std to work, because we need erased-serde.
sval has out-of-the-box support for serde (including in no-std environments) so adding it first already gives consumers a way to capture implementations of serde::Serialize.

The plan is to also eventually offer serde support.

Impact on build times

When sval is enabled through the kv_unstable_sval feature, it increases our compile times by a little bit:

`log` Features	Dependencies	fresh `cargo build` time (best of 5 runs)
`kv_unstable`	none	1.28s
`kv_unstable_sval`	`sval`	1.47s

# What's this all about? This PR adds a new unstable feature for structured logging that lets consumers actually interact with the structure of values. It doesn't do this by exposing its own serialization contract. Instead, it implements traits from a serialization framework called `sval`. I'm open to any philosophical debate on different approaches here! There are two commits that I think demonstrate how it fits together: - [Refactor `value` internals so we can add in-band serialization frameworks easily.](https://github.com/rust-lang-nursery/log/commit/15ccf07784fd831adbc2a2b29e78e382c4bbae79) - [Add `sval` support](https://github.com/rust-lang-nursery/log/commit/06beb05c422e077e51b1f7a1c7b05f01a16885f6). This is the one to look at if you're interested in what impact introducing in-band frameworks has. # What is `sval`? [`sval` is a serialization-only framework](https://github.com/sval-rs/sval) I've been working on specifically for use in `log`. `sval` supports no-std, object-safe serialization for primitives and more complex structures like maps and sequences. It absolves `log` from having to produce and maintain its own serialization contract, so it can stay focused, but lets it provide a complete serialization API for consumers. # What about `serde`? `serde` is the other serialization framework I've been planning to support in-band in `log` because it's ubiquitous (and does its job very well). I haven't started with it because: - It'll require `std` to work, because we need `erased-serde`. - `sval` has out-of-the-box support for `serde` (including in no-std environments) so adding it first already gives consumers a way to capture implementations of `serde::Serialize`. The plan is to also eventually offer `serde` support. # Impact on build times When `sval` is enabled through the `kv_unstable_sval` feature, it increases our compile times by a little bit: | `log` Features | Dependencies | fresh `cargo build` time (best of 5 runs) | | - | - | - | | `kv_unstable` | none | 1.28s | | `kv_unstable_sval` | `sval` | 1.47s |

❤️ 3