Re: [Jmap] Best vs Good enough - adoption of JMAP

[Ned Freed <[e-mail]>]

> On 25 Apr 2017, at 16:46, Neil Jenkins wrote:
> > I think there's been some misconception over the intended semantics of
> > the outbox proposal. The outbox was never intended to be the
> > submission
> > queue, with mail queue semantics. It is intended as a standard
> > mailbox,
> > with mailstore semantics, because it is where messages go **before**
> > they are passed on to submission. The server would validate the
> > message/envelope at the time of moving it to the outbox to ensure it
> > can
> > be accepted for submission later of course. If you have existing
> > mailstore + SMTP infrastructure, implementation is not much more than
> > having some small demon that triggers to take the message from the
> > mailstore and submit it to the SMTP queue at the appropriate time.

> And as soon as you add that "small daemon" (also known as a mail queue
> processing daemon), you've now required the mailstore to also have mail
> queue semantics. This includes key semantics such as: the mail queue
> daemon has full read / delete access to those messages even when the
> user is offline. If the delivery doesn't happen when the user expects,
> the user is going to make a support call, so we now need all the
> monitoring, logging and robustness that comes with a mail queue. And
> addresses that were valid at the time the message entered this mail
> queue can become invalid later, so there has to be bounce-processing for
> when that happens, etc, etc.

Now take these semantics and multiply them by the number of users you have,
which can be in the many millions. And while sometimes you can treat
this as single, system-wide queue for monitoring purposes, sometimes
you'll need to lookup and probably monitor on a per-user basis.

I also assume there won't be a hardcoded name or location for this special
use mailbox. So its specialness arises from some sort of attribute. Can
that attribute be set? Reset? Can it be set on more than one mailbox?
If not why not?

It's not that I can' think of various possible ways to implement all this at
scale. I can. But none of them are easy.

> The only way to have a server-side outbox that is not a mail queue would
> be if messages sit in the outbox indefinitely unless the user is online
> and their client decides to issue a submit command for a message in that
> fictitious outbox.

At which point I don't see why you're bothering with it.

> > From a user experience point of view, this model gives us an
> > understandable conceptual place for messages that are *going* to be
> > sent but have not yet been picked up by the postman, to use a real
> > world analogy.

> This analogy only works with a desktop MUA where the "outbox" is on the
> desktop and thus owned by the "postal customer" (and incidentally, the
> outbox won't empty if the desktop is shut down). The hardware running
> JMAP is not owned but the "postal customer"; it's effectively owned by
> the postman. So an "outbox" on the JMAP server means the message has
> been given to the postman already; the postman is just waiting for the
> right time to release it to the next hop.

Actually, I think it's a great analogy. In the US at least, the post office
imposes specific requirements on mailboxes, including the fact that 
something put in one is now in the custody of the post office, and only
the mailbox owner can remove it.

But the part I like best about the analogy is that while the ability
to have a mailbox at every address in the country is incredibly convenient
for the customer, the cost to the postal service is absolutely staggering.
So much so that nobody other than the post office itself - who is obligated
by history and custom - provides this service at scale.

				Ned