Thanks for your comments.
Yes, Loom is very new and there were recently even blocker when upgrading James beyond Java11
(serialization) though, with that out of the way I don't see bigger issues with adoption (_maybe_
Scala compatibility, but that's huge _maybe_ :-) ).
Out of curiosity - what mailer have you used that garbled the messages?
Wojtek
On 10/10/2023 11:33, btellier wrote:
I'll answer: first thanks for the head up andenthousiasm!Regarding your
remarks, row level security is none essential requirement on james side but an
essential requirement to me ;-)Regarding JPA, sure if we have contributors
making it leave and fixing its flows there is no reason to deprecate and drop
it. Let see what happens. At least we will have an alternative.Regarding
reactive/loom topic, though a strong advocate internally to use newly available
jdk/jre, we always had issues in the community to adopt newer jdk/jre. Second,
I havent seen any detailed return of experience on reactive / loom topic. I'm
personnally expecting perfs to be somewhat similar bit loom might still require
extra scheduling compared to pure reactive implementations... for sure loom
will make it seem less handy...yes i am also expecting citusData to work OOTB
but our dockerised test suite would make great job fact-checking this
assumption, at least with smoke tests...Envoyé depuis mon appareil Galaxy
-------- Message d'origine --------De : Wojtek <woj...@unir.se> Date : 10/10/2023 16:05 (GMT+07:00) À : James Developers List <server-dev@james.apache.org> Objet : Re:
Building a PostgreSQL mailbox for James? Hi Benoit,Please see comments below.On 06/10/2023 23:48, Benoit TELLIER 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 RabbitMQThis sounds very good.> - 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 .Handy, but not essential
(perspective: small, personal mail server running on home machine)> - Be reactive. This can be achieved by using a reactive firendly driver like r2dbc...While reactive has it's
benefits (backpressure), I'm not sure it will be as handy with Loom.> - Ensure that we can easily run on some largely scaling postgres... CitusData ?This should work OOTB if we
stick with Posgress?> An other outcome might be to drop JPA implementation, ideally... (we provide something similar but waaaay better)Hmm... I'm split on this. There was previous
implementation using pure JDBC, but it was deprecated/dropped in favour of using universal JPA. And JPA "just works", but has it's limitations (I'd say storing blobs being
the most annoying).> Ideally I would like to deliver this before september 2024...> > Thoughts?> Would this be something interesting people in here?Very much so!> 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...> Benoit TELLIERWould be nice to have it directly in James main repository
:-)w.---------------------------------------------------------------------To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.orgFor additional commands, e-mail:
server-dev-h...@james.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org
