[
https://issues.apache.org/jira/browse/JAMES-2884?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17219441#comment-17219441
]
Benoit Tellier edited comment on JAMES-2884 at 10/23/20, 3:38 AM:
------------------------------------------------------------------
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!).
I will create tickets for the above mentionned works in the coming days (next
week)
was (Author: btellier):
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: [email protected]
For additional commands, e-mail: [email protected]
