search

duesee / imap-codec

Rock-solid and complete codec for IMAP
Apache License 2.0
35 stars 13 forks source link

refactor: Discuss how (and if) to re-export `imap-types` #398

Closed duesee closed 1 week ago

coalooball commented 7 months ago

Hello again, I think you're right. Using imap-codec::imap-types or imap-codec::types can indeed be confusing, so perhaps importing them separately is the best approach. In my view, imap-types is akin to a tokenizer like Flex, while imap-codec is comparable to a semantic analyzer like Bison.

duesee commented 7 months ago

Hm... I think differently about it. I intended imap-types to be a "pure" collection of IMAP "knowledge" (w/o syntax). These types don't say how they are parsed or serialized but already encode all the knowledge that can be extracted from the IMAP RFC, i.e., when a list is allowed to be empty, what fields are allowed, etc. imap-codec, on the other hand, trusts that the types are correct and implements serialization and parsing. I did this split so that people can possibly exchange imap-codec with something else but still use the "collected IMAP domain knowledge" from imap-types.

Of course, sometimes "IMAP knowledge" and parsing overlap... But that was the idea, at least :-)

duesee commented 1 week ago

Changing my mind for the 1337th time: I think we should keep the imap_types re-export. Not types (because confusing), but imap_types should be fine. Closing :-)