Hi Benoit,
This topic has been discussed for years, I'm happy you finally draw a plan
for it.
To me, the aim for Postgres is small to middle size deployment with
minimal dependencies.
In that regard, having an implementation that spans across all
infrastructure needs is a must have.
So my take would be let's implement everything with PG: blob storage,
search, messaging and various data storage like Event Sourcing and plain
data.
For a user, it will always be possible to plug another piece of
infrastructure if need be (like having better search or store more blobs,
etc).
The only nice-to-have to me would be the multi-tenant goal as you can
always spawn another James instance by domain (and you can use the same PG
if you want by using several databases).
To answer the last questions: I would definitely be interested in using
this implementation (I use JPA for now). I could marginally contribute to
it as I have experience with PG but my time is very limited (unless someone
wants to sponsor my work, of course). I can donate some code related to
Event Sourcing has I have an implementation of an Event Store on top of PG
and some code around messaging. Let me know if you are interested in that
contributation.
In term of strategy, I think that would help James gain popularity among
hobbyist and small businesses, so I think it worth trying.
Cheers,
-- Matthieu Baechler
------- Original Message -------
On Friday, October 6th, 2023 at 23:48, Benoit TELLIER <
btell...@linagora.com> wrote:
Hey there!
The goal: deliver James "stateless email server" concept to smaller
deployments than those addressable with the Distributed server.
Why Postgres? Rock solid. And more options than other SQL stores (see
below)
The requirements would be:
- Leverage the blobStore for binary storage (email bodies +
attachements). Those big binaries are not meant to be stored into SQL rows
- blaming you, JPA!
- Bring choice on blob store : PGSQL native solution (
https://www.postgresql.org/docs/7.4/jdbc-binary-data.html ) for small
deployments OR S3
- Bring choice on search: PGSQL native solution (
https://www.postgresql.org/docs/current/textsearch.html ) for small
deployments OR OpenSearch
- Bring choice on PubSub: PGSQL native solution (
https://www.postgresql.org/docs/current/plpgsql-trigger.html ) OR RabbitMQ
- Enforce strict tenant isolation: domain A won't access domain B data
even if we screw up James access control layer. This can be done with Row
security https://www.postgresql.org/docs/current/ddl-rowsecurity.html .
- Be reactive. This can be achieved by using a reactive firendly driver
like r2dbc...
- Ensure that we can easily run on some largely scaling postgres...
CitusData ?
An other outcome might be to drop JPA implementation, ideally... (we
provide something similar but waaaay better)
Ideally I would like to deliver this before september 2024...
Thoughts?
Would this be something interesting people in here?
Would some people be interested contributing to this effort?
Would some people desire sponsoring this effort?
If this is non consensual, I can also contribute this into
https://github.com/linagora/tmail-backend/ without annoying people in
here...
--
Best regards,
Benoit TELLIER
General manager of Linagora VIETNAM.
Product owner for Team-Mail product.
Chairman of the Apache James project.
Mail: btell...@linagora.com
Tel: (0033) 6 77 26 04 58 (WhatsApp, Signal)
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org
