| 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. |