Re: [Jmap] Draft messages - mutability

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

On 23 Apr 2017, at 18:54, Bron Gondwana wrote:
> I'm starting this thread to discuss the mutability of fields in 
> isDraft: true messages.
>
> In Cyrus IMAPd right now, we create the "MSGID" field as the sha1 of 
> the "RFC822" raw message content as would be delivered over IMAP.  
> That's lovely for non-draft messages (except that we'll probably 
> switch to using blake2 for new messages soon).
>
> But it sucks for drafts, because it means that every time you edit a 
> draft, you get a new MSGID.  Futhermore, you can't edit a draft via 
> JMAP with ['setMessages', {update:{}}] because the fields that you 
> want to edit are immutable, so instead you are doing ['setMessages', 
> {create:{all the fields}, destroy: ["the old id"]}] which is a 
> horrible way to edit drafts.
>
> A somewhat similar discussion is happening over in CalConnect around 
> the idea of saving draft ICALENDAR items on a server without sending 
> out scheduling messages about them until they have finished being 
> edited.
>
> So the question for JMAP becomes: is a "draft message" the same 
> datatype as a "message", or do you handle them completely differently? 
>  Clearly you want to show them in-thread with the message they are in 
> reply to in an interface, but how does that look over the protocol?

I see a lot of cost and no benefit to making a draft a different 
datatype from a message. Now adding a command with semantics like 
draft-brandt-imap-replace to JMAP may be quite reasonable.

		- Chris