duesee/imap-next

Inline crate tag-generator to crate imap-types

Closed this issue · 8 comments

jakoschiko commented
Inline crate tag-generator to crate imap-types
duesee commented

Hm... I can't remember why we said we want to have it it in imap-types... Could as well be integrated into imap-next? Any memories? :D

jakoschiko commented
  • imap-next is not the origin of type Tag and is not using the TagGenerator itself
  • People might want to use TagGenerator even if they don't use imap-next
  • An own crate would be optimal but it would cause too much overhead
  • Given that we only have the crates imap-next, imap-codec and imap-types, the latter is the most appropriate place IMO
duesee commented
  • imap-next is not the origin of type Tag and is not using the TagGenerator itself

I think the question could be different: Do people who use imap-next want to use tag-generator, too? imap-client does, for example. imap-next kinda asks to implement some procedure. Up until this point, we don't care about unique tags so much because it's too low-level.

  • People might want to use TagGenerator even if they don't use imap-next

Yeah maybe... but I guess this argument is true for everything...

  • An own crate would be optimal but it would cause too much overhead

Yeah. I don't think it's worth it...

  • Given that we only have the crates imap-next, imap-codec and imap-types, the latter is the most appropriate place IMO

I would exclude imap-codec. Not sure about imap-next or imap-types. I feel that in imap-types it would be kind of "feature creep". Not so much in imap-next, though, because it's functionality that people using imap-next probably want.

Also, having it in imap-types is kind of providing a "blessed" method to create tags. Maybe we want this...

jakoschiko commented

I think the question could be different: Do people whouseimap-nextwant to usetag-generator, too? imap-clientdoes, for example.imap-next` kinda asks to implement some procedure.

If someone implements a small client or script using the Fragmentizer, they also want to generate Tags. Exposing the TagGenerator to Python might also be an option. In both cases imap-codec or imap-types would be better.

jakoschiko commented

I would exclude imap-codec.

imap-codec is already opinionated how messages should be encoded. TagGenerator fits to that.

duesee commented

Okay, let's put it into imap-codec then? 👯 I think for me it's most important to not let it into imap-types because I really want imap-types to be a collection of types only.

  • 👍1
  • 👎1
jakoschiko commented

To maximize the confusion, here another argument: imap-next does re-export imap-types, but not imap-codec.

duesee commented

I want to fight (for no good reason) for not having it in imap-types. Let's discuss with a donut soon.