Hi Eugen,
You will find my answers inlined. > > I believe you make the assumption that people use and want to use the > full plethora of protocols we have in James. > > Sort of "All or nothing" approach. > > Why do you think it is so? > > I would argue that we should make little assumptions about how people > deploy their infrastructure. > > Maybe I have an existing infrastructure that I know and trust for SMTP > and I just want to use the IMAP server from James. > > Examples: > > 1. I use Amazon Simple Email Service (or Sendgrid or Mailgun) for > sending emails and I just want to be able to customize the IMAP/JMAP > experience and control how I store emails. > > 2. I could use James SMTP as a Gateway for my existing IMAP / Webmail setup. > > 3. I could use James SMTP as a Relay for my marketing SaaS platform. We should of course have an SMTP only server to address these use cases. https://github.com/apache/james-project/tree/master/server/container/guice/jpa-smtp achieve it. > > > But that is not the main argument for having them separate. > > The main argument IMO is that the protocols are quite complex and having > the ability to work on just one protocol at a time has significant > advantages: > > * Lower cognitive effort - I only need to care about this specific > protocol and it's implementation details, not the other protocols. > > This is one huge benefit. > > * Faster development feedback cycle - If I work on IMAP or SMTP I should > get away with running the tests only for that part. > > * Less risk - If I work and break SMTP - the other parts should work. > With the current project structure - it can be hard to say. > > * Easier to adopt by new people - If people care only about SMTP, LMTP > or IMAP - they can contribute only to that. The entry barrier will be > smoother than what we have now. > > * Easier to compose and adapt for new and interesting projects - If we > package them independently and together in a single product (Advanced > Server) we have a showcase of how you can do that. It will be clear that > they are meant to be used in both ways. > > > Having them as separate projects may have the downside of integrating > them together as integrating them requires some form of glue. > > The good side is that we already pay for this integration effort now :). > > We will have to do the effort of splitting them apart while also keeping > the full version. > > This is doable and while it will take time it's not a hard problem IMO. > Regarding Mail Delivery servers, you end up supporting IMAP/JMAP + SMTP. I believe we should be doing a better job at making things optional and packaged separately. I would love to see for instance POP3, ManagedSieve and many other things as extensions, bundled in separated JARs, opt-in. Shipping a small set of servers, with very limited features, each one with their set of extensions. I believe it achieves most of what you describes but without requiring complex integration. > > Our way of using James is not the only way. > > >>> [...] > >>> NOTE: Netty should be upgraded to the latest version, I can do that once >>> we are done with Gradle. >> +1 <3 >> >> Likely a huge effort though... > You questioning my determination ?! (joke) Never ^^ <joke>I don't know which one is easier... Gradle? Or Netty?</joke> > > In time I will change the universe :D . No doubt about it too. Regards, Benoit --------------------------------------------------------------------- To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
