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

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

On 26 Apr 2017, at 16:12, Neil Jenkins wrote:

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

Well, if you believe that and I don't believe that, then the path to 
rough consensus is to start with my proposal and refine it until you 
find it acceptable :-)

So let me refine item 4 a bit. It's my theory that JMAP should have a 
virtual folder / smart folder feature that basically behaves the same 
way as a real/physical folder to the client. I think JMAP should have 
that feature regardless of the outcome of this debate (smart/virtual 
folders is an even more dominant client UI feature than outbox). So 
let's assume we've added that feature to JMAP. Now if the client wants 
to present a server-side outbox view based on my proposal, it just 
creates an "outbox" smart folder. If the client wants to not include the 
release-in-the-future messages in the Sent folder view, it can create a 
smart folder to do that. So now the UI model you prefer is simple to 
implement and it doesn't have the deployment problems a server-side 
outbox creates.

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

Well, it's an implementation burden that disappears completely from the 
system with my proposal. Thus you've made an argument that my proposal 
is simpler (and thus better) than the magic-server-side-outbox model.

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

I happen to like the client-side-outbox UI model, but I believe a 
server-side-outbox is a confusing UI that violates the least 
astonishment principle whenever an offline client is used. But my 
proposal puts no constraints on the UI. If you want to express the 
server-side-outbox UI model using my proposal, we can refine my proposal 
to make that easy (I just suggested a way to do that). The 
magic-outbox-on-server puts a number of constraints on the server design 
which is one of many reasons I dislike that proposal. If you're still 
not convinced, I can enumerate more reasons why magic-outbox-on-server 
is a problem and/or further refine my proposal.

		- Chris