Closed duesee closed 1 year ago
What's the purpose of doing so? I don't see many advantages -- the parser and the types are pretty tightly coupled.
Decoupling is why we probably want to do that. Having an smtp-types crate would allow other Rust implementations to reuse (and hopefully improve on) the type definitions.
This might work better when we don't adapt types in a way to ease parsing. When parsing is easier by using other types they may better life in smtp-codec and are not exposed.
There is much domain knowledge in SMTP that could be collected in smtp-types and I really like the idea of having a "type-safe interpretation" of the SMTP RFC that the Rust community can improve on.
Do you see a disadvantage of decoupling the code? One problem could be that we introduce friction into smtp-codec development. But with smtp-types being a workspace member that should work well (enough)?
We may -- sooner or later -- run into similar problems described here: https://github.com/duesee/imap-codec/issues/2. Making the split now would anticipate that.
Hey @djc, I would like to make the split in the following days. Are you happy to give this a try or do you feel we should discuss a bit more? If so, we could also have this discussion next year.
Hi @duesee, I still think this is the wrong direction. Due to this and some other considerations, we've decided to fork as https://github.com/InstantDomain/instant-smtp (though we haven't spent a lot of effort yet, we will probably spend a bunch more early next year).
Alright. I will make the split then and see how it works out.
I propose to extract an smtp-types crate from smtp-codec. Both crates could remain in a single repository with smtp-codec as the primary workspace member.
I think it is a good time to do that now as the codebase is still relatively small.
Feedback welcome :-)