Michelle Konzack writes:

Hello Sam,

On 2017-03-22 06:35:16 Sam Varshavchik hacked into the keyboard:
> The IMAP command is THREAD REFERENCES.

OK, this is fine since I can setup ANY commands.

> The response consists of
> message numbers, with parenthesis indicating various threads and
> subthreads:
>
> a THREAD REFERENCES UTF-8 ALL
> * THREAD (1)(2)(5 3 4)(6 7)(8)(9)(10 11 12)(13)(14)(15 16 17)(18)(19)
> (20 22)(21)(23 (24)(25))(26)(27)(28)(29)(30)(31)(32)(33)((34)(37)(39))
> (35)(36)(38)(40)(41)((42)(43))(44)(45 46)(47 48)(49 50 ((51)(52)))
> a OK THREAD done.

Hmm, question:

If I understand it right, the

a)  (1) mean a singel messages

but what does

b)  (5 3 4)

mean?  This would look like the message 5 came before 3 and 4 and then

Message numbers are assigned to messages the first time they're seen. If the IMAP server hasn't logged on for a while and is now seeing a bunch of messages for the first time, the order in which the files get read from the directory may not necessarily match the order they were delivered to. So the server may see a reply before the original message, and the REFERENCES sort will rearrange them in chronological order.

c)  (23 (24)(25))
d)  ((34)(37)(39))
e)  (49 50 ((51)(52)))

which look very courious to me.

> The complete specification is a somewhat of a big pill to swallow.
> See https://tools.ietf.org/html/rfc5256

It seems I have to suck it!

Yes.

This is one of the more …involved parts of IMAP. There's a lot of history and legacy involved. It's my understanding that some of the original actors have suffered health problems in recent past; so I don't want to say anything on that account.

But I'll say this. I believe that server-side sorting was a mistake. The most sensible usage model for IMAP is for the client to sync and cache with the server. An IMAP client should sort and thread messages using its cached message metadata and don't hassle the server with it.

A server is a shared resource. It never made any sense to me to offload as much processing as possible to the server. It makes more sense for most of the processing to be done on the client side, with the server's role limited to feeding the raw data to the client. There are more clients than there are servers. Clients, collectively have more shared processing power. A CPU currently busy sorting some knucklehead's ten year mail archive can't do anything else, for other clients. That never made any sense, but that's how IMAP is overall designed, to push as much processing to the server.

And, of course, it's much easier for some hacked-together IMAP-over-web client to send a single command and parse the response, than to do the job by itself.

Attachment: pgptBsBdKg4mw.pgp
Description: PGP signature

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
courier-users mailing list
courier-users@lists.sourceforge.net
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users

Reply via email to