Lettre is an awesome crate to build emails and send them. Himalaya is more general, see it as an “email backend”: you can list and search envelopes, read write reply forward emails, add replace delete flags etc. It is an abstraction of the email domain in order to build clients without reinventing the wheel. Btw Himalaya uses the crate Lettre to build and send emails ;)
This project feels very exciting for multiple projects that I’ve been working on. If I might ask a couple of questions:
How unsupported would it be for me to write a backend that sent something besides emails? For example, a backend that sent and received private messages through the REST api of some site. Is this idea merely misguided, or is the idea that the messages are e-mails a fundamental invariant of the library that would cause the code to fail if the backend didn’t fully support the relevant RFCs.
Is there any support (or roadmap to support) IMAP authentication via OAUTH? My employer’s IMAP server recently switched to only supporting OAUTH based authentication, which has killed 90% of the software I had been using for e-mail. If it’s not on the roadmap, would it at least be a welcomed patch?
Not sure to fully understand, I guess you can try but I am afraid of the result. I would stick to email standards for now. Maybe sth to reconsider later, when the project is mature enough ;)
It is to represent an optional field. This way you can recognize what is mandatory from what is not. It is also useful for the serde crate, which considers Option<T> fields as optional and can therefore be omitted during (de)serialization. For eg, the CLI based on this lib stores the configuration in a TOML file, the Option<bool> means that you can just omit the field (whereas bool would force the user to put it in his config file).
I guess because a simple boolean can’t express disabled vs opportunistic vs required? An enum might have been the cleaner choice, as option is often confusing, but maybe i am missing something :)
To be clear I am asking specifically about starttls, as the code afaict simply uses unwrap_or_default, the default of a bool is false, so it’s not like None is representing some alternative contextual default. A bool seems strictly powerful enough here. Compare to tls which wants to default to true, and the consuming code uses unwrap_or.
I would probably make tls the enum if it were me, and remove starttls altogether but I admit to having a hard time with the names, maybe initiallytls, starttls, insecure
Looks cool! How does it compare to lettre?
Lettre is an awesome crate to build emails and send them. Himalaya is more general, see it as an “email backend”: you can list and search envelopes, read write reply forward emails, add replace delete flags etc. It is an abstraction of the email domain in order to build clients without reinventing the wheel. Btw Himalaya uses the crate Lettre to build and send emails ;)
That makes sense, thanks! Might be a good idea to add that to the README?
Indeed, I realize that the README is not clear enough. Thank you for pointing it out!
This project feels very exciting for multiple projects that I’ve been working on. If I might ask a couple of questions:
How unsupported would it be for me to write a backend that sent something besides emails? For example, a backend that sent and received private messages through the REST api of some site. Is this idea merely misguided, or is the idea that the messages are e-mails a fundamental invariant of the library that would cause the code to fail if the backend didn’t fully support the relevant RFCs.
Is there any support (or roadmap to support) IMAP authentication via OAUTH? My employer’s IMAP server recently switched to only supporting OAUTH based authentication, which has killed 90% of the software I had been using for e-mail. If it’s not on the roadmap, would it at least be a welcomed patch?
My email client
melihas all of its client backend logic extracted into a library,melib. It contains all you mentioned. https://github.com/meli/meli/tree/master/melibWhy an option? What’s the difference between None and Some(false)?
It is to represent an optional field. This way you can recognize what is mandatory from what is not. It is also useful for the
serdecrate, which considersOption<T>fields as optional and can therefore be omitted during (de)serialization. For eg, the CLI based on this lib stores the configuration in a TOML file, theOption<bool>means that you can just omit the field (whereasboolwould force the user to put it in his config file).Thanks, I had a feeling it might be related to something like a config file.
I guess because a simple boolean can’t express disabled vs opportunistic vs required? An enum might have been the cleaner choice, as option is often confusing, but maybe i am missing something :)
An option is already an enum, isn’t it?
To be clear I am asking specifically about starttls, as the code afaict simply uses
unwrap_or_default, the default of a bool is false, so it’s not like None is representing some alternative contextual default. A bool seems strictly powerful enough here. Compare to tls which wants to default to true, and the consuming code usesunwrap_or.I would probably make tls the enum if it were me, and remove starttls altogether but I admit to having a hard time with the names, maybe initiallytls, starttls, insecure
An enum could be more accurate indeed, to avoid confusion between options. I keep in mind, thanks for the idea ;)