imapclient: Add a convenience function to enable whatever go-imap supports

[arnt]

This allows a client to trust go-imap's judgment and not clutter its source with IMAP details.

[arnt]

I woke up this morning with mixed feelings.

This is a protocol, in the old Microsoft sense of the word: A series of function calls that don't necessarily make overwhelming sense to the user. This mentions 9051 and not 3501, but the code uses 3501 by default and (this is a three-step protocol description ⇒) to use 9051, you dial, login and then call EnableAll. Why that last? It makes sense to people with deep IMAP expertise, less sense to a more general audience. A typical "protocol" sequence of calls.

I'd like to do two things:

• make EnableAll the default,
• in a separate PR, add the remaining bits of support for UIDONLY and change FetchMessageBuffer to make UID mandatory and deprecate SeqNum.

This would simplify the API, make all client applications use the same set of extensions, and eliminate the possibility of bugs such as happen when people have the same SeqNum for different messages.

What do you think?

[emersion]

make EnableAll the default

I completely agree! (This was part of #491)

We should probably provide a way to override this - e.g. with a customizable list of extensions to enable on connect in Options, which defaults to IMAP4rev2 (and friends).

in a separate PR, add the remaining bits of support for UIDONLY and change FetchMessageBuffer to make UID mandatory and deprecate SeqNum

FWIW, we already ensure UID is always populated for UID FETCH:

go-imap/imapclient/fetch.go

Line 46 in 7ac47a9

// Ensure we request UID as the first data item for UID FETCH, to be safer.

I don't know if we should be enabling UIDONLY by default, this sounds like a pretty large change. But maybe we should aim for that. Will think about this some more.

[aleksandr4842]

Enable UIDONLY by default - sounds so good

[arnt]

It's a digression, perhaps, but on the subject of UIDONLY: Enabling UIDONLY by default and removing SeqNum has three effects:

1. It permits the occasional speedup (this is not a big factor at the moment)
2. It prevents client programmers from using MSN arithmetic (extremely rare)
3. It prevents client programmers from confusing UIDs and MSNs, one of the most common problems on Stack Overflow.

IMO ③ outweighs ② by a very large factor, and ① is potentially helpful (SELECTing a large folder via IMAP is none too fast).

[emersion]

To somewhat mitigate ③, go-imap has a separate imap.UID type for UIDs.

While we're talking about seqnums, I had a question for a while: how does one implement paging without seqnums? The alps webmail needs to display pages of messages. Each page needs to display a fixed number of messages. This is straightforward using seqnums. How does one implement the same functionality with UIDONLY?

[foxcpp]

Indeed, IMAP implements paging via sequence numbers, removing them will require the client to maintain full local message list and do paging locally. Sequence numbers allow storing very little data on the client - UI operations directly correspond to IMAP commands.

[arnt]

Using sequence numbers was the recommended way to implement paging, ie. it was how Mark Crispin intended it to work. I know quite a few clients that did it, including the one I mostly use. However, I also know quite a few clients that stopped doing it, because it causes a poor user experience when you combine it with threading, and people seem to prefer threading over paging when given the choice.

If you ask for the 20 latest messages and combine messages into threads, sometimes you display 20 threads and sometimes you display just two threads.

There are exceptions — as I mentioned, I use a client that uses paging.

This isn't the area I focus on when I analyse IMAP clients, but I don't look away eityher. I don't think there's one single dominant solution. I've seen UID THREAD … OR UNSEEN SINCE … for example, which can be used to give you all threads that contain either new or unread messages.

[emersion]

Some clients might prefer to display individual messages, and some clients might prefer to show message threads. I don't think go-imap should dictate which UI clients should present to their users.

[arnt]

@emersion your code, your call, of course.

My distaste for MSNs may be coloured by my years of answering questions where people get this wrong. MSN arithmetic can be used to paginate messages, but AFAICT most people who paginate messages do it by issuing something like SEARCH ALL or UID SEARCH ALL and paginating in the client, which even makes sense in many clients. Sigh.

[arnt]

@emersion I think you may find a message from me in your spam folder.

[arnt]

Hi. Any comments on this? It's magnificently simple.

[emersion]

I would prefer this to be the default, rather than an opt-in.

[arnt]

Makes sense. I can update the PR to silently enable everything unless the client explicitly chooses to enable a (perhaps empty) set of extensions.

In that case, how do you prefer to handle the publicly available MSNs? If you ENABLE UIDONLY, you lose MSNs. I see two options:

1. Remove the MSNs from go-imap's API.
2. Document that MSNs are all 0 by default, but leave them in the API for clients that explicitly choose not to enable the relevant extension.

I don't see a lot of clients use MSNs except when forced to, but they can be useful in principle, so it's a choice.