Hi everyone!

With your help I would like to clarify a few things about the current state
of James JMAP support (RFC-8620, RFC-8621) to make better decisions
regarding our own integration.
I hope this info is valuable to other community members as well - this is
why I started a new thread.

I see that the Jira task "Update JMAP implementation to conform to RFC
8620/8621" (https://issues.apache.org/jira/browse/JAMES-2884)
is open but all sub-tasks are closed.
In Changelog I see that the current unpublished version has:
* Partial Support for JMAP RFC-8621: The current implementation status
allow reading mailboxes, emails, vacation responses

Benoit wrote:
> Regarding JMAP, Linagora employed contributors are currently
> implementing RFC-8621 (JMAP mail).

We are very happy to learn that active work is ongoing on that matter.
Is there a more up-to-date document/jira ticket to get the overview of
current status of the work (tickets completed / in progress / yet to be
done)?

The work that the Linagora employed contributors are working on - is it
pushed via PR-s to the main branch often or is it developed elsewhere and
it will be available in the end once it is completed?

How much of that work already made it to James 3.5.0 or does that version
still only support "jmap-draft"?

> Most of the work for reading mails is already done regarding reading mail.
> Writing mails will come in the coming months.

When you write "most of the work reading mails" then do you mean
server-side work or/and client side as well? I see that there is also
ongoing work with front-end:
https://github.com/linagora/jmap-client/tree/release-0.0.31
Do I understand correctly that this UI library goes hand-in-hand with
implementing JMAP on the server side?

> In the meantime I would discourage using the Draft version.

Unfortunately we cannot delay displaying out the emails to users and
composing new email so we have to pick something and implement it (even if
that means we have to rewrite it later).
Currently this only has to have basic functionality (read and send) as it
is needed for MVP.

I understand we have 3 options at the moment:
* pick James 3.5.0 now and rely on jmap-draft. Rewrite UI later to final
jmap spec.
* pick current (unpublished) state of James with partial RFC-8621 support
and start to build on top of that + use
https://github.com/linagora/jmap-client at the same time for UI
Build sending emails on top of jmap-draft. Risk of going live on top of an
unpublished version of James.
* pick James 3.5.0 + some ready-made open source mail client that works on
top of IMAP and once RFC-8621 is all ready and merged (and published as a
new James version) then move the whole UI to using that.

I wonder how many members in the community run production on top of an
unpublished version.
Is it something that generally shouldn't be done?

Thanks
Juhan

Reply via email to