[
https://issues.apache.org/jira/browse/JAMES-2884?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tellier Benoit updated JAMES-2884:
----------------------------------
Description:
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.
was:
At the time this issue was created James implements an outdated draft version
of the JMAP protocol. Since then the protocol has been changed and standardized
as [RFC 8620|https://tools.ietf.org/html/rfc8620] and [RFC
8621|https://tools.ietf.org/html/rfc8621].
James' implementation needs to be updated to match the final specification.
> 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: 1h 50m
> 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]
