clarify intent: replacement of imap-part of email-lib?

[ibotty]

Is this the intended replacement of email-lib's IMAP part?

If so, should convenience functions (like formatting envelope's addresses) be in this crate or imap-types?

[soywod]

No, this is a replacement of the imap crate based on imap-codec and imap-types. Convenience functions should be definitely be at high level, but I'm not sure if it should be part of imap-client or not. Could you detail a bit more your needs?

[soywod]

Is this the intended replacement of email-lib's IMAP part?

But in a sense you are right, this imap replacement is initially for email-lib. Although it can be used independently.

[ibotty]

I have pretty simple needs for now. Just collect messages from IMAP, store them somewhere, and move them to an archive folder. I assumed that this crate is a better starting point than email-lib, because it's more focused. WDYT?

My impressions so far are, that I found the iteration through imap_types' Envelope pretty awkward and thought that there ought to be a way to generate a String from an Address.

[soywod]

Keep in mind that both imap-types and imap-codec are really low level crates. imap-client is at higher level, but remains still "low" level. email-lib could be a better candidate, this is where you will find a list_envelopes with usable headers (including addresses).

Do you need to perform these actions from the code or from the CLI? email-lib from the code is a good starting point, but maybe Himalaya CLI could help you as well. From the CLI you can list, save, and move messages. Easily scriptable, especially with jq. Here some examples:

# Get all envelopes' id
$ himalaya envelope list --page-size 0 --output json

# Save message for a given envelope id
$ himalaya message read 42 --raw > /path/to/message.eml

# Move a mesage to archive
$ himalaya message move Archives 42

Another alternative could be to use a synchronizer like Neverest CLI. It can synchronize a remote IMAP with a local Maildir for example.

[ibotty]

Thank you for your answers. I'd rather do that programmatically.

I follow himalaya and all other tools and look forward switching to it.

[soywod]

I follow himalaya and all other tools and look forward switching to it.

We are really close to release v1, stay tuned 🙏

[duesee]

Hey @ibotty!

My impressions so far are, that I found the iteration through imap_types' Envelope pretty awkward and thought that there ought to be a way to generate a String from an Address.

Sometimes, things are not as simple as they seem in IMAP on a first glace. But: If there is some convinience function missing that is arguably so generic that every higher-level library/application would want to use it, I would happily merge it into imap-types. A good example is iteration through sequences. Here, I could imagine that SequenceSet could get a chunk() method, for example.

Besides from that, it's what @soywod says. If you need specific higher-level functionality, you should climb up the stack.

I see it a bit like generic features trickling-down to lower-level libraries if they prove to be generally useful for all consumers.