Current state of adopting JMAP spec

[Juhan Aasaru <aa...@gmail.com>]

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

Re: Current state of adopting JMAP spec

[Tellier Benoit <bt...@apache.org>]

Le 28/09/2020 à 16:45, Juhan Aasaru a écrit :
> Hi everyone!
Hello Juhan!

First comment: we are starting getting technical and speaking about
implementation details. Maybe this discussion would be a better fit for
the server-dev mailing list.
>
> 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.
Good point, I will reference all development done regarding JMAP
specification as child issues of JAMES-2884

I will provide more insight there too about remaining works.

In the meantime, this annotated copy of the specification [1] will give
you a quick glance at where we are.

[1]
https://github.com/apache/james-project/tree/master/server/protocols/jmap-rfc-8621/doc

> 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)?
I will provide more insight regarding this (see above).

To give more insight, our current implementation strategy is to
implement JMAP RFC-8621 to offer compatibility to our existing WebMail
(OpenPaaS Inbox) with other mail servers (namely Cyrus). We follow a
very pragmattic path and might leave some parts of the spec not
implemented on a short term basis.

Of course, contribution are welcomed to fill the missing bits / help us
with the ongoing effort.

(Of course support could be provided at implementing some parts of the
spec ;-) )

The roadmap regarding this (of course not a commitment from my side) is:
 - Allow modifying emails (keywords, mailboxIds, destroy) => ~ 23/10
 - Allow draft/sending => ~13/11
 - We would then start working on Push.
>
> 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?
We are currently opening PRs (on linagora/james-project repository, but
I would be happy to challenge that choice and rather open PRs on
apache/james-project ;-) ) and merging things on master.
>
> How much of that work already made it to James 3.5.0 or does that version
> still only support "jmap-draft"?
James 3.5.0 supports draft (fully).

RFC-8621 implementation effort started after James 3.5.0 release.
>
>> 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?
As part of the James project, only the server side is available.

But yes, ongoing work is planned as well in Linagora OpenPaaS Inbox
webmail to rely on JMAP RFC-8621, as well as the jmap-client library.

Sorry, I can not give you details straight away (but I can ask). Expect
"front work" to be coming slightly after "backend work".
>
>> 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 think Matthieu advises here are very wise.
>
> 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?

Apache hat on:

The Apache foundation discourages promoting unreleased versions to users [1]

[1] https://infra.apache.org/release-distribution.html#unreleased

Unreleased materials, in original or derived form, *must not* be
advertised to anyone outside of the project development community.

Linagora hat on:

As Matthieu said, it is stable, and I would be realy happy to provide
support ;-)

>
> Thanks
> Juhan
>

Re: Current state of adopting JMAP spec

[Matthieu Baechler <ma...@apache.org>]

Hi Juhan,

I don't have answers to everything but I nonetheless answered a few
questions below.

On Mon, 2020-09-28 at 12:45 +0300, Juhan Aasaru wrote:

[...]

> 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?

I'm not part of it any longer but Linagora always pushed code via PR
and merged to apache master.

[...]

> > 
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.

It's definitely an option. If you are doing a proof-of-concept, you
should adopt this strategy

> * 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.

Don't confuse unpublished with unreleased: James master is very stable
and ready to use. If you intend to do more than a proof-of-concept in
the coming weeks, you should choose this solution.

> * 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 would not do that: IMAP web client are a mess, you will probably
invest much time in this solution and will just drop it in some weeks.

> 
> 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?

I don't really have a personal production setup yet but I would not
fear that: the master branch is usually better than last release
because there's always a bunch of bugs fixed and very few new
introduced thanks to our extensive testsuite.

Cheers,

-- Matthieu Baechler


---------------------------------------------------------------------
To unsubscribe, e-mail: server-user-unsubscribe@james.apache.org
For additional commands, e-mail: server-user-help@james.apache.org