LIST-EXTENDED, part 1: response data item types

[soywod]

The LIST-EXTENDED is a big piece, so I decided to split into independent PRs. Here the part 1 that contains the response data item types.

Refs: #350

[coveralls]

Coverage Report for CI Build 37984604366

Coverage decreased (-0.1%) to 91.59%

Details

• Coverage decreased (-0.1%) from the base build.
• Patch coverage: 17 uncovered changes across 1 file (34 of 51 lines covered, 66.67%).
• No coverage regressions found.

Uncovered Changes

File	Changed	Covered	%
imap-types/src/extensions/list_extended.rs	51	34	66.67%

Coverage Regressions

No coverage regressions found.

---

Coverage Stats

Relevant Lines:	11950
Covered Lines:	10945
Line Coverage:	91.59%
Coverage Strength:	723.78 hits per line

---

💛 - Coveralls

[soywod]

Coverage should improve by itself with codec-related changes (future PRs).

[duesee]

Looks good to me!

I would still need more time to read the RFC and validate all the details to vouch for it. But this is unfortunately not possible for me time-wise currently.

What do you think about this approach? We feature-gate the extension (which is our "still experimental marker") and then we can be generally more relaxed about the code, interface, structure, .... I would then basically do my best to guide you but otherwise just trust that you got the details right. If you notice (in production) that something still needs to change, we can just do the change w/o worrying about semver too much.

[soywod]

While I like the idea, it would make the story more complicated to deliver. Parser changes, so introducing cargo feature for it makes the whole thing even harder to understand, rather than just shipping it. Somehow, I find it overkill for the real needs. IMO it's fine to just merge and make it evolve afterwards on main. Even after release, we are still on v2 alpha.

But this is just my opinion, I respect your choice. I need this feature in Pimalaya, hence my motivation for initiating the work, but I don't have the time unfortunately to add more layer at the moment.

Anyone interested in the feature as well, feel free to take the lead on it meanwhile ;)

[duesee]

Yeah, I understand. The thing is... when I do, e.g., long fuzz runs close to a new release, I need everything to be "correct", specifically, tight types (bijective from type to syntax). Currently, CONDSTORE, for example, is not fuzz-tested because I didn't consider it ready (and think there was a corner case breaking the fuzzer). Now, if we merge LIST-EXTENDED w/o a gate, it must be "correct" for the fuzzer and I need to remember to validate the API before v2. Do you feel feature-gating is so complicated? Maybe we can think about making it easier?

[soywod]

I think it's doable, but I will not be able to take care of it before end of September unfortunately. It can just wait tho, not a big deal so far ;)

[duesee]

Yeah, no hurry. Maybe I can add the gates myself and merge. But currently don't know when. Let's wait a little :-)

[soywod]

I put everything behind a ext_list_extended cargo feature, ready for review. Let's discuss, agree and merge first this part before taking care of other parts #718 and #719.

[duesee]

Hey! I tried to make sense of it but without closely reading the RFC, I'll just trust we are implementing the right thing :-) The structure looks good to me!