Re: [imapext] SEARCHRES RFC5182

[Dave Cridland <[e-mail]>]

On Wed, 10 Mar 2021 at 20:14, Adrien de Croy <[e-mail]> wrote:

> Hi Alexey
>
> ------ Original Message ------
> From: "Alexey Melnikov" <[e-mail]>
> To: "Adrien de Croy" <[e-mail]>
> Cc: "[e-mail]" <[e-mail]>
> Sent: 10/03/2021 11:07:25 pm
> Subject: Re: [imapext] SEARCHRES RFC5182
>
> Hi Adrien,
> On 09/03/2021 23:21, Adrien de Croy wrote:
>
> Hi Everyone
>
> I've been looking into this extension, but it has a number of problems and
> uncertainties in the spec especially:
>
> * in relation to storing results of ESEARCH extensions, it refers to them
> as messages).
>
> Can you elaborate/quote specific text which is confusing?
>
>
>
> When the SAVE result option is combined with the MIN or MAX [ESEARCH]
>    result option, and none of the other ESEARCH result options are
>    present, the corresponding MIN/MAX is returned (if the search result
>    is not empty), but the "$" marker would contain a single message as
>    returned in the MIN/MAX return item.
>
>
> It's not clear if $ is storing the result of the MIN, or something else.
> But I guess those are the same for MIN and MAX - the IDs.
>
> $ only stores message IDs, not messages.  Maybe replace "contain a single
> message" with "refers to a single message" or "contains the message ID"
>
>
Well, it depends on how you see it conceptually.

You could have the server store a list of UIDs always, and translate as
required.

You could also have the server store a list of tuples of (UID,seq), and
filter as needed, updating the sequence numbers if an EXPUNGE occurs.

Or you could have the server store $ as a
std::vector<std::shared_ptr<Message>> or something and format as UID or seq
appropriately.

In all three cases (and more) you're conceptually storing references to
messages, though, and whether they're ids or not is somewhat irrelevant -
when executing the search itself, you're working on messages rather than
identifiers.

The one thing that "$" definitely doesn't contain is a list of integers,
though.


> I guess I should have read it a few more times.  Maybe it's not so unclear.
>
>
> * in relation to reporting errors if the saved results are incompatible
> (e.g. stored SEQ but asked to use as UID or vice versa)
>
> The document is quite clear that $ references message numbers or UIDs as
> appropriate in the corresponding context. So a saved result is never
> incompatible.
>
>
> So we save both UIDs and SEQ and adjust these on expunge, and just use
> whichever one is appropriate in the subsequent commands.
>

I suspect I'd store yet another internal identifier, myself, but loosely
store whatever makes you get the right external behaviour. If UIDs work for
you, I'd store only UIDs and treat a "$" as if it were "UID $" as
needed, for example. But remember it's never a simple string substitution -
otherwise "$" would fail if the saved set were to contain no messages.

As for whether people use this in clients, I don't know - it's been fairly
esoteric until now, but IMAP4rev2 might change this. It's very useful for
"Mark all as" from a search output for online clients, but there aren't
many of those around anymore.

Dave.