james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matthieu Baechler <mbaech...@linagora.com>
Subject Re: My thoughts on JMAP implementation
Date Thu, 17 Dec 2015 09:34:55 GMT

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.


>> 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-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

View raw message