[
https://issues.apache.org/jira/browse/JAMES-2884?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17239115#comment-17239115
]
Benoit Tellier commented on JAMES-2884:
---------------------------------------
Successfully used LTT.RS on top of the JMAP server!
Though it lead to a bunch of code changes! See
https://github.com/linagora/james-project/pull/4089
Support for Thread/get Thread/changes Email/changes Mailbox/changes is needed.
It helped me spotting the following issues in our implementation:
- We generally require too much capabilities
- envelope field in EmailSubmission is optional
- Our implementation was unfriendly with text/plain support (Email/set
Email/get)
- bodyValues was filtered out as LTT.RS do rely on it being implicitly here
when
Experiments where run on top of chibenwa/james-distributed:debug image (adapt
https://github.com/apache/james-project/blob/master/dockerfiles/run/docker-compose.yml)
jmap.properties default version being configured to
jmap.version.default=rfc-8621 see
https://github.com/apache/james-project/blob/master/docs/modules/servers/pages/distributed/configure/jmap.adoc
.
I might not have caught all inter-operability glitches but fixed most.
Email & mailbox display is OK, Email flag update is OK, sending email is OK.
Email deletion takes time but is OK.
> 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: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org
