Example case
assert_matches!(
super::capability_data(b"CAPABILITY IMAP4rev1\r\n"),
Ok((_, capabilities)) => {
assert_eq!(capabilities, vec![Capability::Imap4rev1])
}
);
@jonhoo You wouldn't have any marvelous ideas would you? https://github.com/djc/tokio-imap/pull/48#discussion_r279074302
When in doubt use the same names as the spec: https://tools.ietf.org/html/rfc2045#section-2
Message has all the completely shared fields, and consist of one or more Entitys, which have the mostly-shared fields. An Entity has an enum Body, which can be one of Body::Basic, Body::Message, and Body::Multipart. The text type is a special case of Body::Basic.
@djc @jonhoo Sorry for the late update! Would you two like to have a peek at what I've chosen to do with the dedup? https://github.com/djc/tokio-imap/blob/2e65088e0c9498fb74f04fc00b6ac4b946fc0d78/imap-proto/src/types.rs#L149
Including you Jon, as your crate is upstream from this :) Cheers!
Including you Jon, as your crate is upstream from this :) Cheers!
can we lose the
content_ prefixes on fields? these don't seem to add much
also I think we could just inline
BodyStructureBasic et al into BodyStructure as struct variants
and is there a reason you didn't end up using another crate for the mime types?
Was to keep the struct a bit lighter, though probably not needed
Was going to save that for another PR, but I can start looking into it
I personally like the tuple variant style, nice to match on
Though it's not really that hard to { .. }
different PR for mime types is okay
and
sub_type just subtype
but at this point I'm nitpicking so that's a good sign :)
Might as well get it right the first time
Though if you want to use
type i'll have to escape them like r#type
As it's a reserved keyword
Do you want to use https://docs.rs/mime/0.3.13/mime/struct.Mime.html ?
even better :)
The private ones that are there follow the RFC grouping and naming
Ah that mime crate is all locked down. Can't build it from parts, only parse from str from what I can see :(
ok, let's keep them on the RFC grouping and naming then :)
djc/tokio-imap@83b2890 fails because I can't figure out how to have
body_structure.rssee the macros in parser::macros, anybody have any clues?