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.

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


Mime
View raw message