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 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. > 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. Cheers, =David
signature.asc
Description: Message signed with OpenPGP
