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

[Brandon Long <[e-mail]>]

On Wed, Apr 26, 2017 at 6:45 AM, Ned Freed <[e-mail]> wrote:

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


I think a modern mail store already has need for this type of scheduled
events for many cases, and as such is implemented by many of them.

Off the top of my head, beyond undo send/future send, there is also
automatic emptying of the trash, remind me later, and enterprise style
retention policies.
Once you have such a model, you'll find it useful for a bunch of other
things, such as data migration or applying changes across a very large mail
store.

Brandon