Le 06/07/2020 à 07:13, David Leangen a écrit : > Hey Benoit, > >> Now, that being said, I believe we should always define a "purpose" for >> an API, and here we mixes things in my opinion. > Yes, very good point. I agree 100% > > > >> Are we defining an API for building any arbitrary SMTP server? > My somewhat vague thought is: I get the impression that in the Java world > Apache James has become a kind of reference implementation. It could be that > I have just not found anything else, or that nothing else exists, but in any > case James is “important” in the intersection of “email” and “JVM”. I don't think people are interested by an API allowing them to implement SMTP themselves. (That is quite some work!)
I believe people are interested by a working SMTP implementation where they can "plug" there behaviors or add the commands they miss. > I think we should take it upon ourselves to view James and take on the role > as the “reference implementation” for the JVM. > > This means that we ought to produce java apis that are compliant to the > specs, that anybody could implement if they wanted to as technology develops. > It also implies that we need to give the API lots of thought as this would > become a de-facto industry standard, at least in the JVM world. Heck, if we > do a really great job maybe we can even inspire improvements to the email > spec itself. We should aim high. > > > Take the fictitious case of a new, awesome “super-nutty” technology that is > even better than Netty, but works in a completely different way. I should be > able to make my own super-nutty implementation of smtp based on the James > reference API. Globally +1, if it lives as a separate library, we need a more declarative way off assembling things... (but again we need to consider the costs - return over investment ratio) >> Or are we shipping an SMTP implementation with APIs to add new commands >> support ? > I am no expert in the spect, but aren’t you referring to ESMTP? Or do you > mean something else? > > Even if we make a “reference api for Java”, there is nothing from stopping us > from making an extension mechanism. That mechanism already exists: one can register its own "protocol handlers", be them extra commands or hooks into existing commands. Note that "standard SMTP commands" are bundled into a single ProtocolHandler, not relying on it means you defines your very own SMTP commands. Cheers, Benoit --------------------------------------------------------------------- To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
