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
