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

[Ned Freed <[e-mail]>]

> On Apr 26, 2017, at 10:41 AM, Ned Freed <[e-mail]> wrote:
> > Actually, it offers no utility whatsoever. If you provide the ability to answer
> > such queries at high scale, you do it based on trasactional information
> > produced by the message transport infrastructure. This information is fed into
> > some kind of database that lets you lookup whatever you want for whatever
> > combination of sender, recipient, time window, etc. you want to support.
> >
> > You most certainly don't want to do it by accessing the mailstores. They
> > carry enough load as it is; using them to handle a problem that's easily
> > separable makes no sense.
> >
> > There's also a nontrivial security separation concern here. The access rights
> > associated with being able to look at transaction data are not the same as the
> > rights needed to look at message content.

> These are all good points, but from this perspective then it doesn't really
> matter where the transaction happens as long as the database can be updated.

First, it most certainly does matter where the transaction happens, and the
fact that it isn't at all clear where submission to the transport
infrastructure occurs is a big problems with these magic folder proposals.

Second, just as it makes no sense to use the store as a means of tracking
transactions - and in that regard I'll note that transactions have to be
trackable even if the associated messages have been deleted - it also makes no
sense to use the transaction log as a queue management facility. For one thing,
general-purpose databases tend to suck at implementing anything but the
simplest of queues, and mail queues are anything but simple.

The operational constraints are also very different. The transaction log is
almost always a lower priority thing than getting mail processed. So you can
take some liberties with coherence, update speed, and even reliability and save
some $$$. This is important when you realize that it's often necessary
to retain transacton records for long periods of time. 

In contrast, the queue manager database needs to be up to date at all times,
and in the event of failure it needs to be possible to sync it up to reality
in fairly short order.

				Ned