> I don't think people are interested by an API allowing them to implement > SMTP themselves. (That is quite some work!)
LOL indeed, and I completely agree. But I don’t think that’s the point I’m trying to make. Some organizations may want to create an implementation. The James team may wish to create a new implementation in the future. More likely, people may want to be able to interface with a component (which requires a well-defined API), or compose their own system as you point out below. > I believe people are interested by a working SMTP implementation where > they can "plug" there behaviors or add the commands they miss. I am beginning to think that we may have a fundamentally differing understanding of what an API is. It may be a good idea at some point to have a very clear mutual understanding as to what an “API” is to James. I say that because I would never have written the sentence you wrote. I would have written “a pluggable component”, but never a “pluggable implementation” because no consumers should ever have to plug anything into an implementation. So how does something get plugged? It’s **necessarily** via the API (while the framework should handle the wiring with the implementation, just like Guide does at system startup). Only the API should ever be exposed to consumers. Consumers should never require the implementation code to compile their own code and work with James. It should always be enough to just have the API jar (consisting almost entirely of interfaces), with NO implementation jar (consisting of implementation classes). If you need to plug something into the implementation, then by definition the implementation is also an API, but then it means that you are mixing implementation with API, which is not usually a good practice if you want to have a componentized system. Consumers necessarily only interact with an API, by definition. Another purpose of having a solid API is for versioning. Normally an implementation will continue to advance (bug fixes, optimizations etc.), but for consumers of the API, the code they depend on (i.e. the API only) should change as little as possible. So the API ought to: * Communicate the intention VERY well * Not include “extra” stuff that is not absolutely necessary * Definitely not include any implementations * Allow consumers to minimize dependencies (or at least not require additional transitive dependencies) * Allow consumers to swap different implementations (including different implementation versions) * Allow consumers to use more recent implementations without having to change anything in their own system Here are an article that expresses views about APIs that are similar to mine: * https://developer.ibm.com/technologies/java/articles/api-design-practices-for-java/ It only touches on the differences between an API “consumer” and “provider”, but it would probably be a good thing to bring that into the James vocabulary as well so we can have slightly richer exchanges regarding APIs. I think what you are referring to is that we need to consider how consumers use an API, not just providers, and I totally agree. > (but again we need to consider the costs - return over investment ratio) Always! Completely agree. That is why I mentioned that I was having second thoughts and was starting to think that maybe we could get by WITHOUT having a proper java api (and maybe only a REST api, for instance). In that scenario, consumers of James would ONLY interact either via a REST API or SMTP / IMAP etc. There would simply be no java API because nobody would program against James. I think that could work, but we ought to make our approach explicit to avoid confusion. > Note that "standard SMTP commands" are bundled into a single > ProtocolHandler, not relying on it means you defines your very own SMTP > commands. Ok, these are the types of things that I am very interested in understanding better. Are there any docs anywhere to help me out? Thanks as always for your patience. Cheers, =David
signature.asc
Description: Message signed with OpenPGP
