MBOX-Line: From blong at google.com  Mon Mar 13 12:33:22 2017
To: imap-protocol@u.washington.edu
From: Brandon Long <blong@google.com>
Date: Fri Jun  8 12:34:55 2018
Subject: [Imap-protocol] What is the current consensus on the Recent
	flag?
In-Reply-To: <d0a13d3d-4e4c-4132-a069-ce9da2efe5c3@gulbrandsen.priv.no>
References: <CAPacwgx6aqYdp01-CA0k_saiYmLmCFOizs3TNg4R_PJcMt0WpA@mail.gmail.com>
	<d0a13d3d-4e4c-4132-a069-ce9da2efe5c3@gulbrandsen.priv.no>
Message-ID: <CABa8R6vAXuhR-80Pzc4hLcb8u3VFT8nFtm0D1BdqWFXrLWYStQ@mail.gmail.com>

Simultaneous access does make it more complicated, you have to maintain a
lock across or at least issue a locked RMW to wherever you're storing that
value.

Never seemed all that worth it to me, especially trying to sync with
non-IMAP access in our case.

Brandon

On Sat, Mar 11, 2017 at 12:50 AM, Arnt Gulbrandsen <arnt@gulbrandsen.priv.no
> wrote:

> Hi,
>
> I've never seen it in real use either.
>
> But it's simplish to implement along with MSNs. You keep a UID
> persistently, "the last UID for which some session has seen \recent". In
> the code where you assign MSNs for each session, you look at whether each
> message has UID>that, and if so, you set \recent in that session only and
> increase the threshold.
>
> Simple to do, but worthless. Your call ;)
>
> Arnt
> _______________________________________________
> Imap-protocol mailing list
> Imap-protocol@u.washington.edu
> http://mailman13.u.washington.edu/mailman/listinfo/imap-protocol
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman13.u.washington.edu/pipermail/imap-protocol/attachments/20170313/223a4a20/attachment.html>
