Re: [Jmap] Draft messages - mutability

[Bron Gondwana <[e-mail]>]

Yeah, we have a strip attachments feature at FastMail. Generates a new email with same body structure but the part for each attachment replaced with a short bit of text explaining that the attachment was stripped. It's a feature that is needed less now that quotas are gigabytes rather than handful of megabytes.

The downside of the draft id is that you would need to search on it. The message object id will already have a fat index.

Bron.

On Wed, 26 Apr 2017, at 08:36, Stu Brandt wrote:
> Agreed. Mutability opens the door to needing to sync only those body 
> parts (or portions thereof) that changed since last sync point. It's 
> also unlikely that a mutable content concept could be restricted to just 
> "drafts" since there are all sorts of use cases around a user wanting to 
> change the content of messages they received. In Alto, for example, once 
> a user sees the photo stack the inevitable question is "how do I delete 
> these old photos...I want to keep the email but without the photos".
> 
> We can totally re-envision the mail store as a versioned document store, 
> which I agree would be interesting, but that seems like a significant 
> scope change for JMAP to cover it. And it seems like we have enough of 
> that already.
> 
> - Stuart
> 
> On 4/24/17 7:00 PM, Ted Lemon wrote:
> > If drafts are mutable, the implication is that synchronization based on
> > message ID can't happen without something like a version modifier. At
> > which point why not make every message versioned?
> >
> > On Apr 24, 2017 9:35 PM, "Neil Jenkins" <[e-mail]
> > <mailto:[e-mail]>> wrote:
> >
> >     __
> >     On Tue, 25 Apr 2017, at 11:02 AM, Chris Newman wrote:
> >>     I see a lot of cost and no benefit to making a draft a different
> >>     datatype from a message.
> >
> >     I don't see any benefit to making it a different data type. However,
> >     what we currently have is that, like IMAP, a message is immutable
> >     except for flags/mailboxes. This is a pain for client authors trying
> >     to keep track of a single draft as it is saved through multiple
> >     revisions (especially when the user has multiple clients). One
> >     possible solution to this is to simply say any message with the
> >     \Draft flag set is fully mutable (while keeping the same id). I
> >     think we would also want the server to enforce that a message cannot
> >     be changed from/to draft state after creation. If it starts a draft
> >     it stays a draft, or vice versa.
> >
> >     From a protocol perspective, since most messages won't be drafts
> >     (with a normal user) you still get the efficiency of immutable
> >     messages (you only have to refetch flags/mailboxes, not the whole
> >     message) for most of the messages in the mail store. But it will be
> >     easier for MUAs to handle drafts, and particularly allow for a much
> >     better experience when editing the same draft message across
> >     multiple devices.
> >
> >     Neil.
> >
> >     _______________________________________________
> >     Jmap mailing list
> >     [e-mail] <mailto:[e-mail]>
> >     https://www.ietf.org/mailman/listinfo/jmap
> >     <https://www.ietf.org/mailman/listinfo/jmap>
> >
> >
> >
> > _______________________________________________
> > Jmap mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/jmap
> >
> 


-- 
  Bron Gondwana
  [e-mail]