On 14/12/2015 10:45, Benoit Tellier wrote:
I gonna start answering this one ...
Le 14/12/2015 08:58, Matthieu Baechler a écrit :
And the last part ...
On 13/12/2015 12:43, Tellier Benoit wrote:
[...]
- I heard JMAP handles unique ID accross email copies. I guess you are
compelled to support it. How do you plan to manage it across
implementations ?
That's a very interesting question.
What we think would be a good design is :
1/ make Message a top-level entity, that means it should exist outside
any mailbox. From a datastore point of view, it means having an
identifier that is not bound to the mailbox (unlike uid). Let's call
that Message.id
Yes, we agree.
I have one question : what should be the type of message.id ? I think it
can be easily MailboxId...
Message.id is probably going to be a MessageId (as it's not a mailbox).
This type would be backend specific, like MailboxId.
2/ Message <-> Mailbox relation is no longer a composition but an
aggregation, it means that Message lifecycle is not bound to Mailbox and
that Message.uid is now a relation id
Ok
3/ Some backends may not be able to express this new design (we think
about filesystem backend) so we think backend have to expose their
capabilities and a backend consumer should require a mandatory
capabilities list. That way, we could go forward without being limitated
by backends not feature-rich enough. The compatibility should be checked
at server start and prevent incompatible components to start.
I think this is a very good idea. I can already think of other
"capabilities", like :
- custom IMAP flag handling
- custom IMAP flag indexing
- quota processing
- ACL handling
- Thread ID handling
...
It would be, in my opinion an answer to the multiplication of feature
while supporting multiple backends. Such a feature is definitely needed.
Agreed
There's at least the Quota part the is not solved yet : how do you count
Messages duplicated in several Mailboxes ?
We can count it once per mailbox, It would be correct but does not
reflect your storage reality.
We can attach the message blob to the ID (independently of all messages
copy) thus we can pay the cost in terms of quota on the first append,
and not in the face of copies.
The problem with above behavior is if I append message to QuotaRoot A,
then copy it to a mailbox belonging with QuotaRoot B. Delete it in quota
root A. Then quotas for QuotaRoot A will still take the message into
account, and not QuotaRoot B (what is not expected). Recovering from
such a situation seems really hard to me.
What do you think about it ?
We should probably take the simplest solution : count the message size
on every folder.
--
Matthieu Baechler
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org
