Re-export imap-proto

[FelixPodint]

Hello,

While trying to parse and put envelope data into a database I had problems reaching imap-proto types. Re-exporting imap-proto fixed this problem, while adding imap-proto to my project resulted in type conflicts.

---

This change is 

[jonhoo]

So, this is a tough call ­— on the one hand, I'd like to disconnect imap from imap-proto in terms of its public type signatures so that we don't have to cut a breaking release if imap-proto has done the same, but on the other we use so many types from imap-proto that that dream may be infeasible, in which case re-exporting may be a good idea. @mordak what do you think?

[mordak]

We already re-export a few imap_proto types where it makes sense and is convenient, and it seems a bit inconsistent to re-export only some of them. We could probably just re-export imap_proto::types to make things consistent, and maybe simplify some of our internals a bit without re-exporting the entire imap_proto API.

I would be curious to see the original problem and understand what exactly is not working or it too difficult. I think this problem happened because we do not re-export imap_proto::types::Envelope but we do return it in Fetch::envelope()? I would be interested in seeing if just re-exporting imap_proto::types solves the original problem as well.

[FelixPodint]

1. Originally I wanted to convert Envelope to bytes, but ended up with something similar:

fn address_to_bytes(address: &Address) -> Vec<u8> {
    let mut temp: Vec<u8> = vec![];
    if let Some(name) = &address.name {
        temp.extend(name.iter());
        temp.extend(b" ");
    }
    if let Some(adl) = &address.adl {
        temp.extend(adl.iter());
        temp.extend(b" ");
    }
    if let Some(mailbox) = &address.mailbox {
        temp.extend(mailbox.iter());
        temp.extend(b" ");
    }
    if let Some(host) = &address.host {
        temp.extend(host.iter());
    }
    temp.extend(b";");
    temp
}

fn vec_address_to_bytes(vec_address: &Vec<Address>) -> Vec<u8> {
    let mut temp: Vec<u8> = vec![];
    for address in vec_address {
        temp.extend(address_to_bytes(address));
    }
    temp
}

fn envelope_to_bytes(message: &imap::types::Fetch) -> Vec<u8> {
    let envelope = message.envelope();
    match envelope {
        Some(envelope) => {
            let mut result = vec![];
            if let Some(from) = &envelope.from {
                result.extend(b"from: ");
                result.extend(vec_address_to_bytes(from));
                result.extend(b"\r\n");
            }
...

And yes, problems started with Fetch::envelope() returning type which cannot be passed to functions, because that type was nowhere to be found in the library. I think I will rewrite this to use Envelope.

2. Do I need to fix all those checks?

[urkle]

@jonhoo see 01fc90c as an alternate approach. Here I just exposed the needed prototypes that are used/exposed in the public API of this types in this crate.

[jonhoo]

@urkle Unfortunately that doesn't solve the problem. Our API stability would still be tied to that of the imap-proto crate. If we bump the major version of imap-proto. that is still a breaking change for our API. Re-exporting might reduce the likely amount of breakage, but it's still a breaking change.

[urkle]

@urkle Unfortunately that doesn't solve the problem. Our API stability would still be tied to that of the imap-proto crate. If we bump the major version of imap-proto. that is still a breaking change for our API. Re-exporting might reduce the likely amount of breakage, but it's still a breaking change.

Currently you are re-exporting some pieces (in unsolicited_response).

Another option is to look at separating from using imap-proto and using your own parser that you can maintain in lock-step with this crate. As it was rather cumbersome and annoying having to update the two crates just to get ACL support working. (and that that whole feature is now dependent on 2 different maintainers releasing updates)

[jonhoo]

I don't think we actually need our own parser. Instead, the trick is to just wrap all the output types in newtype wrappers that we control. It's not pretty, and more than a little annoying, but the alternative of being tied to imap-proto also isn't sustainable given the frequency with which it needs breaking changes.