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... > > 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. > > 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 ? > > Maybe we missed some design issue, feel free to push this discussion > further. > --------------------------------------------------------------------- To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
