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

[Neil Jenkins <[e-mail]>]

On Thu, 4 May 2017, at 07:16 AM, Chris Newman wrote:
> I prefer a protocol model where it is possible for the client
> to easily> identify "future release date is in the future" messages and to
> apply an> "unsend" action to those messages. I further believe the model
> shouldn't> limit the "unsend" action so it can only be used with that set of
> messages.

I agree.

> And I'd prefer a model where there is no explicit state change
> in the mail store when a "future release" message is released as that> keeps the mail queue and mail store components independent.

I think this is the one real disagreement left, but I certainly take
your point that you would prefer not to have to do this, so we should
try to find a solution where this is optional.
> I'm ok if the base JMAP spec requires implementation of future release> and unsend for future release messages.

I'm not actually sure we should mandate servers implement future release
in order to claim base JMAP support, but we should have the interface
specified for servers that do support it.
> I'd prefer to leave details about message tracking (including whether
> a message can unsent) and unsend for other messages to a JMAP
> extension.
Agreed.

> Virtual/smart mailboxes are a common mail UI feature. As a mail user,> I'd like my virtual mailboxes to look the same in different
> mail clients> to the extent possible.

I agree these are very useful, and it would be great if they were
exposed at the protocol layer so they could be synchronised between
clients. I'm not sure whether it's a good idea to try to put them in
the base JMAP Mail spec though; depends how much we think they will
slow down implementation, and whether they're strictly necessary. If
the counts are optional then they should be pretty easy to
implement, but every extra "optional" is of course more effort to
maintain down the line.
>> One proposal that might satisfy everyone: a "futurerelease"
>> mailbox role is added (this is the IMAP SPECIAL-USE representation in>> JMAP).  Servers can **optionally** have a mailbox with this
>> role; if it>> does, clients SHOULD place future-release messages in here, but like>> "sent" **can** put the message in any mailbox(es). Servers that
>> have this>> mailbox MUST move messages from this mailbox to the sent mailbox at
>> future release time (which may just be based upon the future-release>> date, or may be actually based on releasing it to the mail queue).
> 
> This is something I could implement easily as long as there's no
> requirement that the mail store verify the message was actually
> released> from the mail queue at the future release time. But I'm not
> sure it's a> good design as it raises some issues... Messages in the futurerelease> mailbox have been submitted/sent, so should that mailbox also have the> \Sent special use?

No, I'd say it would just have a "futurerelease" role. I think this is
reasonable; clients which understand this role have all the information
they need from this, and clients that don't may be confused by two
mailboxes with the "sent" role.
>  I think a futurerelease virtual mailbox (based on the sent
>  mailbox) is a> cleaner way to do this (and optionally a sentandreleased
> virtual mailbox> for clients desiring that).

The issue with this is synchronising changes with the server. The
results of a message list (a sorted query on the set of messages)
normally only change in response to some kind of state change on the
server. If futurerelease were a *virtual* mailbox, the results would
change depending on *when* you fetch the query, even if there is no
change in server state. So this would require a new mechanism to notify
the client of when the query results might have changed (presuming you
want a client to be able to be always up to date without polling
everything, which I think is a reasonable requirement).
Neil.