Re: [Jmap] Draft messages - mutability

["Chris Newman" <[e-mail]>]

On 24 Apr 2017, at 19:24, Neil Jenkins wrote:
> On Tue, 25 Apr 2017, at 12:18 PM, Chris Newman wrote:
>> Why is it important to keep the same ID when modifying a draft?
>>  The approach draft-brandt-imap-replace uses is to include the new
>>  ID in the> response to the modification operation.
>
> That's great if you're only using one client to edit the draft. But
> consider the following scenario:
> 1. I start a draft on my laptop. I'm not finished, it's still open on
>    the screen and I just put the laptop to sleep.
> 2. I continue editing on my phone. Maybe I finish and send it or
>    maybe I don't.
> 3. I go back to my laptop, which immediately resyncs with the server 
> to
>    find out what's changed.
> Now with immutable messages, all my laptop MUA can see is that the 
> draft
> has been deleted from the server, but this might just mean there's a
> newer version of the draft. I can see the newer draft but can't know 
> for
> sure it's an update to the one I have open or not. So I can either
> resave the draft that's open (which could cause a duplicate old draft 
> to
> "reappear" in the Drafts mailbox), or I can just delete it and hope 
> for
> the best (and the user can reopen the new draft if they still hadn't
> finished sending).
>
> With mutable messages, I would see there's an update to the current
> message I have open. If I know the user's last changes were saved to 
> the
> server I would just fetch the update and immediately show this 
> instead.
> If the user has made other changes then I know we have a split and I 
> can
> prompt the user what they want to do. It's a much better user
> experience.

I'd prefer not to make the common-case resync more complicated just to 
handle the rare case of multiple clients editing a draft. But if you 
think it's important to handle that case, another option is to introduce 
a draft unique identifier that's preserved across replace operations; 
then the client can know that a new message is a new version of a 
previous draft and the problem is resolved without making common-case 
resync more complicated.

		- Chris