Hi David, On 23/05/2020 04:16, David Leangen 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/[email protected]/msg65858.html > <https://www.mail-archive.com/[email protected]/msg65858.html> > [2] https://www.mail-archive.com/[email protected]/msg65814.html > <https://www.mail-archive.com/[email protected]/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”.
Great proposal! Thanks! I would suggest "JAva Mail Enterprise Solutions" > > 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/[email protected]/msg65720.html > <https://www.mail-archive.com/[email protected]/msg65720.html> > [4] https://www.mail-archive.com/[email protected]/msg65653.html > <https://www.mail-archive.com/[email protected]/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). +1 > > > 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. > +1 > > 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. +1 But I would mention "James Customization" before "James Toolkit" James server profiles offers several mechanisms for a user to customize easily the behaviour of his JAMES server. Here are some examples [1] [2] [1] http://james.apache.org/howTo/mail-processing.html How to customize mail processing [2] http://james.apache.org/howTo/custom-listeners.html > 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 agree with this proposition. It sounds closer to what the PMC tries to deliver. > > 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. I find this sentence confusing. > So each of the ready-made servers would include its own user manual appropriate for that assembly. Yes > I wonder… with a system like Antora, perhaps an assembled James product should also include an assembled user manual. This gives me the impression that as user I can generate the documentation for the James server I just assembled, that is not a 'ready-made' server. This would be great but sounds like a lot of work. > Does this go in the right direction? Yes Thanks for this proposal. > > > Cheers, > =David > > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
