fdm VS tracing

I wrote this to execute fdm on new messages, so my VPS can deliver email to its own local Dovecot instance and my home machine can fetch them with minimal delay - without otherwise being tightly coupled to my external email setup.

When I switched from GMail’s web client to a local client, I used fdm over POP to send everything to a local maildir. Then I set up a cronjob that calls fdm every five minutes (again, over POP) to check for new mail. Bear in mind that depending on your GMail settings, GMail’s copies of emails can be auto‐deleted upon POP download. If you still want to access email through the web or IMAP, make sure that’s set properly.

This actually seems to have maybe changed quite recently, however this mechanism seems inconvenient for users to use, requiring additional scripting (meaning, shelling out to a command), continually generate a new access token to use with fdm, on a per-account basis, hourly. Yuck.

I came across fdm, which is fast, lightweight, and simple to configure. It fetches mail. That's it. The config is literally a couple of lines for a single mailbox.

The video description is as follows:

In this stream, we peel back the crust on the tracing crate — https://github.com/tokio-rs/tracing/ — and explore its interface, structure, and mechanisms. We talk about spans, events, their attributes and fields, and how to think about them in async code. We also dig into what subscribers are, how they pick up events, and how you can construct your own subscribers through the layer abstraction. For more details about tracing, see https://docs.rs/tracing/latest/tracing/.

> What's been your biggest issues around ergonomics/amenities for OpenTelemetry?

I can't speak generally, but in the Rust ecosystem the various crates don't play well together. Here's one example: <https://github.com/tokio-rs/tracing/issues/2648> There are four crates involved (tracing-attributes, tracing-opentelemetry, opentelemetry, and opentelemetry-datadog) and none of them fit properly into any of the others.

The tracing (logging) mechanism in an asynchronous codebase (tracing).

Tracing is Tokio's alternative for async code.

At a technical level, in Rust, both [tracing]https://crates.io/crates/tracing) and log are entire ecosystems (though for the latter at least there's also third party logging frameworks), and there's at least a bridge from log to tracing.

I am using https://github.com/tokio-rs/tracing for logging purposes in my application. I would like to develop a feature wherein logs should be saved to a database table (via sea-orm). Something similar is this, but it does not solve my needs fully.

I've used the tracing infrastructure with tracing_flame to profile some hot paths in async code: https://github.com/tokio-rs/tracing/tree/master/tracing-flame

Oh nice! IIRC when I checked, it was the Unicode tables that smashed the code size. I recently hit the same issue with the tracing crate, where a crate feature (for env var filtering) pulled in regex and my binary was suddenly 1MB bigger.

I know about tools such as tracing, jaeger or tracy. While having a complete tracing could be a potential solution, these tools don't work with no_std.

tracing by itself only outputs log data, you need to consume them in a subscriber, the tracing-subscriber crate exists for this. (example)