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

[Ned Freed <[e-mail]>]

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

Maybe it is from the client side, but from the server side it's very, very
different. The key point is there's no longer a queue that has to be maintained
in a mailbox.

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

That's from the client perspective.

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

It's not even close to being the only additional component.

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

We don't have any such plumbing in our product that's connected to folder or
messages. And I cannot think of a single case where we've been asked for a
feature that required it.

				Ned