split transports to new crate? about lettre HOT 6 CLOSED

I've been working on an SMTP crate that uses Tokio and nom, and builds on parts of lettre. This is very rough, right now: https://github.com/stephank/tokio-smtp/

from lettre.

Done in master but not published on crates.io yet.

from lettre.

Sounds like a good idea. The email builder is not really good, and some other implementations look better (like https://github.com/mikedilger/email-format for example).
I also think the API (SendableEmail) for transports is much too limited, and should be completely changed before a stable release.

It mmight also be a good idea to split it into different crates, as some may require quite heavy dependencies (like an HTTP client).

from lettre.

In what way do you want to change the SendableEmail trait? The only quirky thing about it is the requirement for the message id.

Against dependency bloat I recommend using Cargo features in the lettre-transports crate.

from lettre.

Mainly been able to stream message content, and maybe a specific interface for higher-level types of transports (HTTP APIs, etc.). We could also avoid the Message-ID, or maybe make it optional.

Cargo features are a good solution indeed.

from lettre.

Published on crates.io (since Oct 8, 2017), closing.

from lettre.