Le 06/07/2020 à 13:12, David Leangen a écrit : > [...] >> 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 Globally +1 > > 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. +1 to be more specific.
We should at least extract the API of what todays works well: - Extra commands - Hooks (additional behaviors) And extract an API achieving these goals from the protocol-smtp package. > 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?Not really Not really. http://james.apache.org/server/dev-provided-smtp-hooks.html defines hook you can rely in for the default implementation. https://github.com/apache/james-project/blob/master/src/site/xdoc/server/dev-extend-smtp-hook.xml might be helpful too. Which is not much for "hooks" already. Given the part of the quote you chose, that might not be what you are looking for... Regarding writing your own commands, there is even less. http://james.apache.org/protocols/index.html is too generic http://james.apache.org/protocols/smtp.html is blank > Thanks as always for your patience. > You are welcome, and I'm happy you raise such an opportunity to re-qualify or document things! > > Cheers, > =David > > --------------------------------------------------------------------- To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
