Re: [Jmap] simpler future release & unsend without outbox (was Re: Best vs Good enough - adoption of JMAP)

["Adrien de Croy" <[e-mail]>]

my personal experience with the outbox folder is that it's a pain in the 
neck..

it means if I need to find a message I submitted, there are now 2 places 
to look for it instead of one, depending on its state.

This doesn't seem like a bonus to me, rather the opposite.

Adrien


------ Original Message ------
From: "Neil Jenkins" <[e-mail]>
To: "[e-mail]" <[e-mail]>
Sent: 27/04/2017 11:12:12 AM
Subject: Re: [Jmap] simpler future release & unsend without outbox (was 
Re: Best vs Good enough - adoption of JMAP)

>On Wed, 26 Apr 2017, at 05:54 PM, Chris Newman wrote:
>>I'll describe a model that achieves my goal […]
>>1. Get rid of the server-side outbox. We only have a drafts folder and 
>>a
>>sent folder.
>>
>>2. Add a submission command with envelope (same structure as SMTP
>>envelope but JSON syntax and quoting). We pass this command a 
>>reference
>>to a draft message in the drafts folder, and if the submission 
>>succeeds,
>>the message is moved to the sent folder with the envelope as an
>>annotation. The envelope can include the already-standard future 
>>release
>>extension.
>>
>>3. Add an unsend command which takes a reference to a message in the
>>sent folder. If the unsend succeeds, the message can be moved back to
>>the drafts folder as part of this action. How the server correlates a
>>message in the sent folder with a message in the mail queue is an
>>implementation detail; the spec need not specify that detail in order 
>>to
>>provide the functionality with this model.
>>
>>4. Add a way to search/select messages in the Sent folder that may be
>>possible to unsend.
>
>From a protocol perspective, this model is basically identical to the 
>outbox model proposed. The only difference is that rather than put the 
>messages that can still be recalled in a separate "outbox" mailbox, you 
>put them in the sent mailbox and require some kind of search. The only 
>extra component your server will need is something that moves the 
>message from outbox to sent when it can no longer be recalled; I 
>seriously don't think this is a huge implementation burden. As Brandon 
>has pointed out, modern mailstores need this kind of "scheduled events" 
>plumbing for a number of user-facing features, and it has already been 
>implemented at scale in a number of systems.
>
>From a user interface perspective, I maintain it is clearer for the 
>user for these to be two separate mailboxes, and it also has the 
>advantage that mailboxes have a message count so MUAs can more easily 
>see if there are any messages waiting to be sent still. (I would expect 
>most MUAs to hide the outbox when empty.)
>
>Neil.