I've been waiting a bit to reply to this to see if there's a polite way to answer, but there isn't.
You suffer from a disease, and it's far too bloody common amongst people who design IETF standards.
You're optimising a rare case, where in the worst case you would be re-iding the bulk of the messages delivered in a time period of a few hours, leading clients to have to re-fetch the metadata again (note: it's only the modseq that would change in our design - the UUID is still globally unique and unchaged).
That's no worse than "FETCH 1:* FLAGS" now.
And in exchange for this slight benefit, you would cause EVERY SINGLE CLIENT EVERYWHERE to implement a significantly more complex protocol which requires 4 roundtrips to resync.
Talk about a dog with a very big, very waggy tail.
I'm sorry, but I can't take this suggestion seriously. I've seen too many protocols which are designed with this sort of focus on the worst cases. You have to make sure they don't totally suck - but the important place to optimise is the common case.
...
It turns out there is a way you can gain almost all of the benefits you're looking for - which is delayed MODSEQ allocation. Newly delivered messages can be created with no MODSEQ. When you sync with another either client or server, you allocate a MODSEQ higher than than any which the other end has seen.
Which means you only pay an extra cost if a JMAP peer or client connects at both ends during the link downtime.
Comments
I've been waiting a bit to reply to this to see if there's a polite way to answer, but there isn't.
You suffer from a disease, and it's far too bloody common amongst people who design IETF standards.
You're optimising a rare case, where in the worst case you would be re-iding the bulk of the messages delivered in a time period of a few hours, leading clients to have to re-fetch the metadata again (note: it's only the modseq that would change in our design - the UUID is still globally unique and unchaged).
That's no worse than "FETCH 1:* FLAGS" now.
And in exchange for this slight benefit, you would cause EVERY SINGLE CLIENT EVERYWHERE to implement a significantly more complex protocol which requires 4 roundtrips to resync.
Talk about a dog with a very big, very waggy tail.
I'm sorry, but I can't take this suggestion seriously. I've seen too many protocols which are designed with this sort of focus on the worst cases. You have to make sure they don't totally suck - but the important place to optimise is the common case.
...
It turns out there is a way you can gain almost all of the benefits you're looking for - which is delayed MODSEQ allocation. Newly delivered messages can be created with no MODSEQ. When you sync with another either client or server, you allocate a MODSEQ higher than than any which the other end has seen.
Which means you only pay an extra cost if a JMAP peer or client connects at both ends during the link downtime.