Hi David, Thank you for keeping up with that topic.
We somehow already analyzed that topic in the past and this is what we came to : 1. James is a mail server that can integrate your business logic 2. James is a mail framework : you can build you application and specific needs into James 3. James is a set of libraries: you can take parts of James and build something that is not a mail server with it So to answer to what you propose, I really think we did a mistake at trying to do these 3 things. Everytime I open a web page that say very general things about a software that try to do too much, I just go away. It think James should be promoted as a flexible Mail Server. Other usages will emerge if we reach that goal. It's why I prefer "Mail Server". Another point is "Enterprise": I think that any "Enterprise" software is suspicious at best. Free Software should empower anybody. So I would propose to drop that word. Finally, I think that Java is not a selling point any longer, the JVM is. So I would rather propose "JVM Mail Server". Coming back to the documentation: James is pointless without (at least) Mailets. I would focus the documentation mainly on the Mail Server target and would promote customization as a top-level concept of it. My 2 cents Cheers, -- Matthieu On Fri, May 22, 2020 at 11:16 PM David Leangen <apa...@leangen.net> wrote: > > Hi! > > Based on things that Benoit has been explaining to me (in threads such as > [1], [2]), I have been thinking about the top-level description of James. > > [1] https://www.mail-archive.com/server-dev@james.apache.org/msg65858.html > <https://www.mail-archive.com/server-dev@james.apache.org/msg65858.html> > [2] https://www.mail-archive.com/server-dev@james.apache.org/msg65814.html > <https://www.mail-archive.com/server-dev@james.apache.org/msg65814.html> > > Currently, James is said to mean “JAva Mail Enterprise Server”. > > However, it seems to me that it ought to be “JAva Mail Enterprise > Solution”. > > It has been mentioned a few times recently that James is “like a toolkit”. > If an enterprise has a “problem” they wish to solve with regards to emails, > they could use James as a “solution” to that problem in one of 3 ways: > > 1. Out-of-the-box > 2. Assembled > 3. Customized > > Out-of-the-box > --------------------------- > > The first way of using James is by using a pre-assembled, generic > “solution” (or “product” — will bring this topic up again in thread [3]). > > As already discussed ([4]), there are currently 3 ready-made products: > > * James Distributed Mail Server > * James Advanced Mail Server > * James Basic Mail Server > > [3] https://www.mail-archive.com/server-dev@james.apache.org/msg65720.html > <https://www.mail-archive.com/server-dev@james.apache.org/msg65720.html> > [4] https://www.mail-archive.com/server-dev@james.apache.org/msg65653.html > <https://www.mail-archive.com/server-dev@james.apache.org/msg65653.html> > > These were just assembled by the James team as described below as a > convenience for those who want a “common” solution for emails. These common > solutions probably match a large majority of cases. (Just guessing. I have > no data whatsoever.) > > Other than a serious lack of documentation, this way of using James is > quite stable and works well. If the documentation were improved, then it is > possible that adoption of James could potentially grow by those who require > a “common” enterprise solution for emails. > > It is possible to start out with a Basic Server, then migrate as necessary > to an Advanced, then eventually a Distributed Server. (Would be good to > make the migration path clear, maybe?) > > Additionally, as the needs of a user of an out-of-the-box solution evolve, > they could eventually grow into an assembled solution. > > All this means that by choosing James, one can start small, and scale as > required (both up and down). > > > Assembled > --------------------------- > > If an out-of-the-box product is not sufficient, then a more appropriate > solution to one’s current needs can be assembled using the “Java Mail > Enterprise Solution”. > > James provides a number of components that can be assembled into a > product. Given the number of components and their implementations, there is > a large number of possible combinations, so a large number of potential > products that could be assembled without any need for customization. > > However, although this is the goal, currently not all components are > well-formed, and it is not evident how to do this type of assembly. It is a > long-term objective of the James Project to provide a “toolkit” that makes > this type of assembly easy. > > > Customized > --------------------------- > > If an assembled solution is still not enough, James provides numerous > customization points. > > The main mechanism (but not the only one) by which the server can be > customized is the Mailet. > > > > In addition to these 3 ways of building a James-based product, James > provides a comprehensive API that allows fine-grained management of all > aspects of the system. Thanks to the API and the Mailet technology, James > provides a high level of integration with other systems or applications. > > (By the way, I think the API and the Mailets are incredibly powerful. > These are what attracted me to James in the first place. If more people > understood how these could be used to provide useful solutions to problems, > perhaps that could also help with adoption. Is there any list about how > people are using these to solve their problems?) > > > > Does this sound about right? This “type of solution” approach moves away > from the current documentation, which separates more by “type of user”. > > Currently, the doc is structured like this: > > * User Manual > * Operator Manual > * Administration Guid > * Developer Resources > > If we make the change I describe in this email, it would change to > something more like: > > * James Concepts > —> Describes the core domain concepts > * James Server Products > —> Describes the out-of-the-box pre-assembled server products > * James Toolkit > —> Describes how to assemble a product with the James "toolkit" > * James Customization > —> Describes how to use Mailet (and whatever else) to customize > behaviour > > I wonder… with a system like Antora, perhaps an assembled James product > should also include an assembled user manual. So each of the ready-made > servers would include its own user manual appropriate for that assembly. > For that to work, each component has to be very well defined and documented. > > > Does this go in the right direction? > > > Cheers, > =David > > > > >
