Hello Tobias! According to http://james.apache.org/mail.html James General Mailing List is for general discussions relating to the running of the project, it is the public list of the James project management committee (PMC) and is a public list open to all. *Do not send mail to this list with James software problems* -- that's what server-user@james is for.
I suggest we move the discussion in there. Le 18/11/2020 à 03:46, Tobias Verbeke a écrit : > L.S. > > Following a short discussed on the Gitter channel, I was advised to post my > question on the mailing list for public discussion. Thank you for the follow up on that topic. > The question was whether there were plans within the James team to support > the calendar and contacts extensions of JMAP in James (similarly to Cyrus). > > Independently of the plans, I was wondering whether people would agree the > implementation of these extensions is within scope for the James project, > since it would be boil down to 'fully' implementing the JMAP spec or whether > there would be a consensus limit the James project to the email part of the > spec. > > Looking forward to learning about your opinions! I clearly understand the operating ease of having all JMAP stuff handled by a single solution to support groupwares. However the Apache James PMC have no prior experience with Calendar and Contact domains. If you start supporting things like JMAP contact/calendars, then people will ask for legacy protocols support to use their preferred mobile client for instance, and we might end up supporting these protocols as well. James is already a too complex project, according to recent new contributors feedbacks. I'm unsure adding such unbounded complexity would help regarding that. The project also had a bad experience with 'not-finialized-yet specifications' leading to a costly full rewrittes a few years down the line (we did just that for RFC-8621, and are about to end a 1 year rewrite effort). What could be possible as a solution: - Have contacts calendars handled by a server other than James. Have some proxy logic somewhere to direct "email" calls to James, "contact / calendar" calls to the other server. Note that unifying identities would likely not be an issue as different JMAP accounts can be used for "email" and "contact / calendar". Maybe projects like https://sabre.io/ would be interested for handling the "contact / calendar" part Building the JMAP proxy would likely be a not too hard implementation effort. The more extensions there is, the more unlikely a single server handle them all. I believe the IETF working group would highly appreciate an OpenSource JMAP proxy server... Maybe starting a thread there can bring some answers https://datatracker.ietf.org/wg/jmap/about/ . Of course documentation on "how to set James as an email server inside a JMAP ecosystem" would fit in the project, IMO. - James is an easy to extend email server, adding extra JMAP methods as an extension should be easy to write. The DEV mailing list would likely provide support and guidance on how to do so. I would see such an effort as a separated project, but pointing to it would IMO be a good idea. Cheers, Benoit > > Best, > Tobias > --------------------------------------------------------------------- To unsubscribe, e-mail: server-user-unsubscr...@james.apache.org For additional commands, e-mail: server-user-h...@james.apache.org
