[
https://issues.apache.org/jira/browse/JAMES-2884?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17203653#comment-17203653
]
Benoit Tellier commented on JAMES-2884:
---------------------------------------
I finished attaching the existing tickets, related to JMAP RFC-8621 development
as subtasks of this issue.
The implementation, appart from minor aspects, is mostly complete for
Mailbox/get, Mailbox/set, Email/query (partial supprot), Email/get, downloads.
Mailbox/query is very partially implemented, back reference are supported.
We maintain an annotated version of the specification, allowing to track
status, as well as understand current limitations:
https://github.com/apache/james-project/tree/master/server/protocols/jmap-rfc-8621/doc
Currently, Linagora will contribute the following parts:
- Enhance search via Email/query (add text & body criterion, add AND OR NOT
operator support. As we are working on it, I will create the issues straight
away.
- Start Email/set implementation (I should be able to create tickets next
week):
- Resetting + partial updates of keywords
- Resetting + partial updates of mailboxIds (move)
- Destroying emails
On a middle term time schedule (starting at the end of October), we planned
developments:
- Saving drafts & other Email/set create
- Sending emails via EmailSubmission entity. Please note that this work is
limited to EmailSubmission/set create and do not imply storing
EmailSubmissions, thus the implementation will be very pragmatic, very partial.
- Porting the (custom) filtering extension
On a long term time schedule (Q1 2021) we plan to work on the push.
Please note that non of the above is a commitment ;-)
Cheers,
Benoit
> Update JMAP implementation to conform to RFC 8620/8621
> ------------------------------------------------------
>
> Key: JAMES-2884
> URL: https://issues.apache.org/jira/browse/JAMES-2884
> Project: James Server
> Issue Type: Improvement
> Components: JMAP
> Reporter: cketti
> Assignee: Antoine Duprat
> Priority: Major
> Time Spent: 3.5h
> Remaining Estimate: 0h
>
> Historically, James is an early adopter for the JMAP specification, and a
> first partial implementation was conducted when JMAP was just a draft. IETF
> draft undergo radical changes and the community could not keep this
> implementation up to date with the spec changes.
> As off summer 2019, JMAP core ([RFC
> 8620|https://tools.ietf.org/html/rfc8620]) and JMAP mail ([RFC
> 8621|https://tools.ietf.org/html/rfc8621]) had been officially published
> (will not change anymore). Thus we should implement these new specifications.
> Point of attention: part of the community actively rely on the actual 'draft'
> implementation of JMAP existing in James. We should ensure no changes is done
> to that 'draft' protocol is done while implementing the new one.
> The proposed approach is to keep the current implementation under the
> `jmap-draft` name, and implement step by step a `jmap` compliant
> implementation, that will be exposed on a separate port. No modification in
> `jmap-draft` integration test should be counducted.
> This will allow existing `jmap-draft` clients to smoothly transition to
> `jmap`, then trigger the classic "deprecation-then-removal" process.
> For now, as a first implementation step, we will only support `jmap` on top
> of memory-guice (ease testing, speed of development). To ensure a
> `storage-compliant` behavior of newly introduced storage APIs, we should use
> persistent datastructures (like the one in vavr) and always deep-copy objects
> at the storage boundaries.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
