You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-dev@james.apache.org by David Leangen <ap...@leangen.net> on 2020/05/22 21:16:47 UTC
Apache James top-level description
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
Re: Apache James top-level description
Posted by David Leangen <ap...@leangen.net>.
Hi Matthieu,
> 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
This actually sounds very similar to:
>> James as a “solution” to that problem in one of 3 ways:
>>
>> 1. Out-of-the-box
>> 2. Assembled
>> 3. Customized
I am not putting #3 on your list into scope at this time, though. I do not think I’ll have time for that.
> 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.
Yes, I agree, and I do the same thing. If a website describes something in an abstract way, and I am not able to quickly figure out how to apply it to my objectives, I quickly lose interest. I would even say that you and I are not alone: most people act that way IMO.
That is indeed one of the objectives that I am trying to accomplish, i.e. *not* to make documentation that is not practical.
The idea is:
>> 1. Out-of-the-box
The wording “out-of-the-box” usually implies that you just need to plug it in, and it should work. This should be good for those who are impatient. They should be able to get up and running very quickly.
If indeed they can get set up with a working server quickly, then the objective would be accomplished, and the user would be satisfied. I have not yet been able to test if this is actually the case or not. If it’s not currently possible, then I would argue that even more urgently than fixing documentation, this should be the primary short-term objective of the entire team right now.
>> 2. Assembled
If we can show concretely (with a few examples) how “easy” it is to assemble a James product, then on the contrary, I think it would be very interesting.
>> 3. Customized
Again for those who need it, if we can show concretely (with some examples) how “easy” it is to customize a James-based product, then it would be interesting.
But the key is not the wording, the key is the ease with which it can be done. If there are too many technical hurdles, then THAT is the barrier IMO.
I cannot judge because I am still not there yet.
> 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”.
Yes, that is indeed true. But aren’t the other parts also important?
> 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”.
Both of these points are good points…. but then we’ll have to either find a new name for the project, or find different words that match “James”. Or maybe drop James as an acronym and just come up with a completely different story about why the project is called “James”.
> 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.
Ok, point taken about Mailets.
(Half-jokingly) how about:
JVM Asynchronous Mailet Event Stream
Joke aside, I will refine my approach a bit, but unless I am misunderstanding you, it still sounds to me like this is generally the right direction to take. Hopefully once I proceed a bit further it should become a little clearer.
Cheers,
=David
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Apache James top-level description
Posted by David Leangen <ap...@leangen.net>.
>> Do you think we could keep the acronym `James`?
>
> But we can very well keep James name without it being an acronym.
I agree. In the current version of the new docs, that is indeed the solution I have taken.
The only question is: do we just use “James” without any explanation and leave it a mystery? Or should there be a “history” section that explains where the name came from?
Cheers,
=David
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Apache James top-level description
Posted by ma...@gmail.com.
On Mon, 2020-05-25 at 14:01 +0700, Tellier Benoit wrote:
>
[...]
>
> Do you think we could keep the acronym `James`?
>
>
I don't know if this name brings value to the project or not. Is it
known? Does changing it would help catch new users more than loosing
current users ?
I definitely have no opinion about that.
But we can very well keep James name without it being an acronym.
We probably should not play the acronym retrofit game unless with find
a very very good solution.
Cheers,
--
Matthieu Baechler
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Apache James top-level description
Posted by David Leangen <ap...@leangen.net>.
> We could very well change the "e" meaning in the James acronym too.
>
> Something like `JAva Mail Extensible Server/Solutions` ?
Thanks for thinking about this.
The “JAM” part of “JAMES” brought to mind “JAMstack”.
Taken from this page: https://jamstack.wtf/
[JAM = JavaScript + APIs + Markup]
For JAMES, JAM could be something like JVM - API - Mailet == JAM
ES could be, as Benoit mentioned “Extensible Server / System / Solutions”
Re: Apache James top-level description
Posted by Tellier Benoit <bt...@apache.org>.
I am lurking a bit within that interesting conversation and might only
answer some points I might have something to propose.
This thread discusses what we try to do as a project. In my previous
post on this list, I (tried to) explain the legacy behind the James
project goals. But I of course agree rationalizing the James project
goals to align it with what the current contributors try to deliver.
Now branding being definitely funny:
On 25/05/2020 03:54, Matthieu Baechler wrote:
> [..]
> 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.
Coffee thoughts:
We could very well change the "e" meaning in the James acronym too.
Something like `JAva Mail Extensible Server/Solutions` ?
> Finally, I think that Java is not a selling point any longer, the JVM is.
> So I would rather propose "JVM Mail Server".
I globally agree with this point, that converges with the growing usage
of Scala programming language within the code base.
Do you think we could keep the acronym `James`?
A quick search on google for adjective starting by `A` lead to the
following results:
- `Adaptable` enforces the idea you can adapt James to your needs.
However I would see it as a duplicate of the `Extensible` mentioned above.
- `Advanced` is a bit more boiler plate....
- <joke>awesome</joke> :-)
>
> 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,
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Apache James top-level description
Posted by Matthieu Baechler <ma...@gmail.com>.
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 <ap...@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
>
>
>
>
>
Re: Apache James top-level description
Posted by David Leangen <ap...@leangen.net>.
>> Does this go in the right direction?
>
> Yes
Thank you once again, Benoit.
I will take the documentation in this direction, then.
Cheers,
=David
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Apache James top-level description
Posted by Tellier Benoit <bt...@apache.org>.
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/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”.
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/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).
+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: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org