[jira] [Commented] (JAMES-2884) Update JMAP implementation to conform to RFC 8620/8621
[ https://issues.apache.org/jira/browse/JAMES-2884?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17314514#comment-17314514 ] Benoit Tellier commented on JAMES-2884: --- I took time this evening to open a couple of tickets regarding spec compliance, unimplemented parts of the specification. The goal is to provide several sub-tasks for possible other kind contributors wanting to help. Some tasks are straight forward given our data model, some others requires data storage. Cheers, > 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: Benoit Tellier >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
[jira] [Commented] (JAMES-2884) Update JMAP implementation to conform to RFC 8620/8621
[ https://issues.apache.org/jira/browse/JAMES-2884?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17247835#comment-17247835 ] René Cordier commented on JAMES-2884: - https://github.com/linagora/james-project/pull/4114 mandates core specs with JMAP calls. Issue has been fixed on LTTrs => https://github.com/iNPUTmice/lttrs-android/issues/55 > 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
[jira] [Commented] (JAMES-2884) Update JMAP implementation to conform to RFC 8620/8621
[ https://issues.apache.org/jira/browse/JAMES-2884?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17240721#comment-17240721 ] Benoit Tellier commented on JAMES-2884: --- Thanks Lan! https://github.com/linagora/james-project/pull/4093 better documented Authentication on top of the new Jmap specification following https://github.com/linagora/jmap-client/issues/87 which showed this was needed ;-) > 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
[jira] [Commented] (JAMES-2884) Update JMAP implementation to conform to RFC 8620/8621
[ https://issues.apache.org/jira/browse/JAMES-2884?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17240664#comment-17240664 ] Lan Khuat commented on JAMES-2884: -- Hi everyone, I'm Lan, a developer of the Apache James project. In the coming month, i will be working on the JMAP Push for James, starting with a POC for the Mailbox/changes part. First we want to have a repository to track all the changes made to Mailbox objects, in memory implemented. See: https://issues.apache.org/jira/browse/JAMES-3459 You can take a look at the PR which handle the aforementioned ticket here: [https://github.com/linagora/james-project/pull/4088 |https://github.com/linagora/james-project/pull/4088] Tickets need to be handled: * Implement a MailboxChangeListener: https://issues.apache.org/jira/browse/JAMES-3460 * Implement Mailbox/changes method: https://issues.apache.org/jira/browse/JAMES-3461 * Cassandra version of the MailboxChangeRepository: https://issues.apache.org/jira/browse/JAMES-3462 * *state* property handling: https://issues.apache.org/jira/browse/JAMES-3463 * *oldState* & *newState* handling: https://issues.apache.org/jira/browse/JAMES-3464 * differentiate changes between a Mailbox and messages belong to it: https://issues.apache.org/jira/browse/JAMES-3465 > 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
[jira] [Commented] (JAMES-2884) Update JMAP implementation to conform to RFC 8620/8621
[ 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
[jira] [Commented] (JAMES-2884) Update JMAP implementation to conform to RFC 8620/8621
[ https://issues.apache.org/jira/browse/JAMES-2884?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17237207#comment-17237207 ] Benoit Tellier commented on JAMES-2884: --- https://github.com/linagora/james-project/pull/4060 made the JMAP implementation documentation more readable on github > 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
[jira] [Commented] (JAMES-2884) Update JMAP implementation to conform to RFC 8620/8621
[ https://issues.apache.org/jira/browse/JAMES-2884?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17236577#comment-17236577 ] Benoit Tellier commented on JAMES-2884: --- Work on EmailSubmission/set and Email/set is pretty much complete (note that there is some existing limitations! We only implemented a subpart of RFC-8621). It is time to try our implementation with other clients (say, https://github.com/iNPUTmice/lttrs-android !) In order to do so, I propose to configure the version of the protocol served by default when the client specifies no version in the accept headers... https://github.com/linagora/james-project/pull/4059 contributes that. > 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
[jira] [Commented] (JAMES-2884) Update JMAP implementation to conform to RFC 8620/8621
[ https://issues.apache.org/jira/browse/JAMES-2884?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17225080#comment-17225080 ] Benoit Tellier commented on JAMES-2884: --- https://github.com/linagora/james-project/pull/3985 contributed some refactoring (package relocations, class splitting) > 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
[jira] [Commented] (JAMES-2884) Update JMAP implementation to conform to RFC 8620/8621
[ https://issues.apache.org/jira/browse/JAMES-2884?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17219441#comment-17219441 ] Benoit Tellier commented on JAMES-2884: --- Here is an update of our implementation effort. In the coming month we are planning to: - Work on Email/set create, allowing saving draft, saving messages prior sending them. - Work on EmailSubmission/set create unlocking sending emails. - Work on attachment upload. - Work on MDN submission ( https://tools.ietf.org/html/draft-ietf-jmap-mdn-15 ) Our goal is to contribute the missing bits of RFC-8621 to power OpenPaaS INBOX webmail on a subset of RFC-8621. We do not target a feature complete implementation. We might plan, however, evaluation of our compatibility with LTT.RS ( https://github.com/iNPUTmice/lttrs-android ) android application by the end of the year. Regarding RFC-8621 adoption in INBOX webmail frontend, we plan so far adoption for the read path by the end of the year (Email/get, Email/query, Mailbox/get, Mailbox/query, session route, downloads). We will also perform a performance testing campaign, whose goal is to validate "no performance regressions" between JMAP draft and JMAP RFC-8621. To do so, we will port Linagora's Gatling scripts to RFC-8621 (see https://github.com/linagora/james-gatling). Adapting gatling performance scripts is out of the scope of the Apache James projects but we should share our findings here as well. Now jumping in the details... *Work on Email/set create, allowing saving draft, saving messages prior sending them.* - We will support creating empty body emails with convenience headers setted up first - Then we will support specifying a HTML body - Then we will support specifying attachments - Then we will support specifying addition headers parsed as text form. This is intended for instance for asking the receiver to send "read receipts" *Work on EmailSubmission/set create unlocking sending emails.* This will include basic calls. No storage is enabled, this will be "shoot and forget". We plan support for "onsuccessUpdateEmail" allowing EG to move messages to the sent mailbox. Note that identity not being specified, we will rely on the From field of the submitted EML to specify the sender (given that this is allowed!). > 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
[jira] [Commented] (JAMES-2884) Update JMAP implementation to conform to RFC 8620/8621
[ https://issues.apache.org/jira/browse/JAMES-2884?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17206022#comment-17206022 ] René Cordier commented on JAMES-2884: - [https://github.com/linagora/james-project/pull/3851] adds few fixes on the ADR related to this topic > 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
[jira] [Commented] (JAMES-2884) Update JMAP implementation to conform to RFC 8620/8621
[ 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: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Commented] (JAMES-2884) Update JMAP implementation to conform to RFC 8620/8621
[ https://issues.apache.org/jira/browse/JAMES-2884?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17040599#comment-17040599 ] Benoit Tellier commented on JAMES-2884: --- https://github.com/linagora/james-project/pull/3086 contributed an architecture decision record on this topic. > 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
[jira] [Commented] (JAMES-2884) Update JMAP implementation to conform to RFC 8620/8621
[ https://issues.apache.org/jira/browse/JAMES-2884?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16932002#comment-16932002 ] Tellier Benoit commented on JAMES-2884: --- I did also create a first batch of sub-tasks to reflect the first steps of the aforementioned approach. Concretely, the first target is: Getting a 'memory-guice' powered 'jmap' server, distinct from 'jmap-draft', handling only the 'echo' command in a RFC-8620 compliant way. > 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: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Commented] (JAMES-2884) Update JMAP implementation to conform to RFC 8620/8621
[ https://issues.apache.org/jira/browse/JAMES-2884?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16931983#comment-16931983 ] Tellier Benoit commented on JAMES-2884: --- https://github.com/apache/james-project/pull/164 renames existing JMAP implementation into `jmap-draft` > 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: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Commented] (JAMES-2884) Update JMAP implementation to conform to RFC 8620/8621
[ https://issues.apache.org/jira/browse/JAMES-2884?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16931982#comment-16931982 ] Tellier Benoit commented on JAMES-2884: --- https://github.com/apache/james-project/pull/163 did rename some class to closely match RFC-8620 wording. > 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: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
