Subject: Re: [Extra] RFC on proposed RFC - CREATEDMODSEQ

From: Bron Gondwana <[email-masked]>
Date: Sun, 01 Jul 2018 17:55:23 +1000

Yeah, fair enough. I guess I should write up global modseq first and
only propose this as part of that or something.
I will write it up anyway just as a secondary description of how we're
doing it in Cyrus to support the jmap changes.
Bron.

On Sun, Jul 1, 2018, at 09:11, Timo Sirainen wrote:
> On 30 Jun 2018, at 16.26, Bron Gondwana
> <[email-masked]> wrote:>> 
>> On Sat, Jun 30, 2018, at 22:02, Timo Sirainen wrote:
>>> On 30 Jun 2018, at 7.13, Bron Gondwana <[email-masked]>
>>> wrote:>>>> 
>>>> I'm working on a doc (and implementation) for an extension to
>>>> RFC7162 - CREATEDMODSEQ.  It adds said field on both mailboxes and
>>>> emails.>>> 
>>> What's your planned use case(s) for this? I can't really think
>>> of any.>> 
>> So the main use-case I'm working with at the moment is "phone client
>> wants to create a notification to user of new mail, but NOT throw up
>> a new mail notification if the user just moved an email from Inbox to
>> a notified folder in another client".  So the phone client needs to
>> be able to distinguish "this message has newly arrived in the
>> mailstore" vs "this message has just been updated in some way".> 
> This requires the global modseq space for it to work. Also, an
> alternative to this feature might be to just auto-add some $Copied /
> $Moved keyword..> 
>> This piece of data is also being used in JMAP to underly the
>> calculation for whether a message (or thread) should be in the added
>> or changed result.> 
> I tried quickly looking at the jmap spec to see what exactly these
> meant, but didn't find it. So I guess copying/moving would be better
> as "changed" then?  Again for the same reason of not showing
> notifications of copied/moved mails?> 
>> And likewise for mailboxes, the createdmodseq on mailboxes is used to
>> distingish between "got renamed" and "newly created".> Nice, but again I don't really see how clients would use this.
> 

--
  Bron Gondwana, CEO, FastMail Pty Ltd
  [email-masked]

---

From: Bron Gondwana <[email-masked]>
Date: Fri, 06 Jul 2018 14:35:40 +1000

Coming back to this... we did consider early on the idea of a
"MODSEQROOT" or "CONDSTOREROOT" in the same way that there's a
QUOTAROOT - with all folders under the listed folder having the same
global modseq counter and being able to fetch that counter.  With this,
you only need to keep one state per modseqroot to know if mailboxes or
their contents have changed.  This would be more flexible than the
current Cyrus model of "it's per user", which doesn't handle shared
mailboxes particularly well.
I've put an item in AOB to discuss this in Montreal if we get that far.
Bron.

On Sun, Jul 1, 2018, at 17:55, Bron Gondwana wrote:
> only propose this as part of that or something.> 
> doing it in Cyrus to support the jmap changes.> 
> Bron.
> 
> 
>> <[email-masked]> wrote:>>> 
>>>> wrote:>>>>> 
>>>>> emails.>>>> 
>>>> of any.>>> 
>>> a new mail notification if the user just moved an email from Inbox
>>> to a notified folder in another client".  So the phone client needs
>>> to be able to distinguish "this message has newly arrived in the
>>> mailstore" vs "this message has just been updated in some way".>> 
>> $Moved keyword..>> 
>>> or changed result.>> 
>> notifications of copied/moved mails?>> 
>>> And likewise for mailboxes, the createdmodseq on mailboxes is used
>>> to distingish between "got renamed" and "newly created".>> Nice, but again I don't really see how clients would use this.
>> 
> 
> --
> _________________________________________________
> Extra mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/extra

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Fri, 6 Jul 2018 09:04:17 +0200

Wouldn't it be better to say that if the server advertises global modseq to 
a particular user, then that applies to all mailboxes the user can open? 
Simple semantics for the client, no little-used or hard-to-test special 
cases, and covers both of the big use cases.

Arnt

---

From: Bron Gondwana <[email-masked]>
Date: Fri, 06 Jul 2018 17:43:15 +1000

That means you need a global modseq for the entire server. Right now
we're doing it per user. Either that or you need to not have shared
mailboxes that any user can subscribe to (eg bulletin boards)
Bron.

On Fri, Jul 6, 2018, at 17:04, Arnt Gulbrandsen wrote:
> Wouldn't it be better to say that if the server advertises global
> modseq to> a particular user, then that applies to all mailboxes the user
> can open?> Simple semantics for the client, no little-used or hard-to-test
> special> cases, and covers both of the big use cases.
> 
> Arnt
>

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Fri, 6 Jul 2018 09:58:10 +0200

On Friday 6 July 2018 09:43:15 CEST, Bron Gondwana wrote:
> That means you need a global modseq for the entire server. 
> Right now we're doing it per user. Either that or you need to 
> not have shared mailboxes that any user can subscribe to (eg 
> bulletin boards)

Is that case really common enough to warrant requiring extra complexity? 
After all, CONDSTORE already requires clients to support NOMODSEQ.

Arnt