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/10 02:41:48 UTC
James configurations
Hello,
Since I am very new to James, I have the advantage of looking at the available documents with fresh eyes. For that reason, I am currently working on trying to update the documentation, and have submitted a PR to get the ball rolling. [1]
I will need some help for much of this work. I hope that you are willing to spare a few minutes to help me help the community.
I am writing my questions here because I am trying to “develop” the documentation, but if you would like me to move to the user list, I could do that.
Right now, I am interested in this section of the README.adoc file [2]:
How to run James in Docker
• Run James with Guice + Cassandra + RabbitMQ + Swift + ElasticSearch
• Run James with Guice + Cassandra + ElasticSearch
• Run James with Guice + JPA + Lucene
• Run James with Spring + JPA
As a new reader trying to figure out what is going on, I am already lost. To get me started, can you please tell me:
1. What are these configurations for? Why would I want to choose one over another? Why should I care?
2. How do these get wired / configured? Is there anything I need to do? If yes, what? If no, how does that work?
3. Are there any other possible configurations that are not in this list?
Thanks!
=David
[1] https://github.com/apache/james-project/pull/189 <https://github.com/apache/james-project/pull/189>
[2] https://github.com/apache/james-project/blob/master/README.adoc <https://github.com/apache/james-project/blob/master/README.adoc>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: James configurations
Posted by David Leangen <ap...@leangen.net>.
Thank you, Matthieu.
>> * Is the name “product” set in stone? Would it be possible to call
>> it a “profile” for example?
>
> I don't really care. I don't really like "product" name. Maybe
> "profile" is better but I'm not sure.
Ok, thank you. So unless somebody raises an objection, I will go with “profile”.
(En passant, même en français, en regardant la définition Larousse, “profile” me semble être tout à fait raisonnable.)
>> * (Guice + Cassandra + RabbitMQ + Swift + ElasticSearch) —>
>> Clustered
>> * (Guice + Cassandra + ElasticSearch) —> Advanced
>> * (JPA + Lucene) —> Basic
>
> Is "Distributed" to ambiguous for you (instead of Clustered)?
No, “distributed” is just fine. I will make the change.
>> - Uses Cassandra, RabbitMQ, Swift, and ElasticSearch behind the
>> scenes
>
> We support S3 too and we'll probably talk to Swift via S3 protocol
> soon. Also, more people understand S3 than Swift or even Object
> Storage. I would than replace Swift with S3 in that description.
Ok, no problem.
>> - Uses JPA + Lucene behind the scenes
>
> I really don't like using JPA in product/profile description. I'd
> rather describe where data is store.
>
> As you may have read, we have one product/profile using derby (embeded
> database using local filesystem) and another using mariadb/myql.
Ok, so how about either “file system” or “RDB”?
>> It would be great to also have a “minimal” Profile that uses the file
>> system and a minimal number of dependencies, if possible.
>
> It's JPA with derby.
Sure, that works.
Unless somebody has something else to add, I will create a new PR for this section of the documentation, and we can continue the discussion there.
Cheers,
=David
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: James configurations
Posted by Matthieu Baechler <ma...@apache.org>.
Hi David,
Before commenting, just keep in mind that some other James developers
can have different opinions than mine, they may disagree with our
current discussion outcomes.
Also, most of us are not english-native people so it may explain why we
don't always use the best words to explain things.
On Mon, 2020-05-11 at 22:03 +0900, David Leangen wrote:
>
> [...]
> My first follow-up question:
>
> * Is the name “product” set in stone? Would it be possible to call
> it a “profile” for example?
I don't really care. I don't really like "product" name. Maybe
"profile" is better but I'm not sure.
[...]
> I would like to change the wording for the User Manual in order to
> expose the fewest concepts as possible, or at least to be able to
> spoon feed the users better, rather than making them try to swallow
> too much all at once.
Sounds good.
> I would like to rename these Products / Deployments / Profiles to
> something like:
>
> * (Guice + Cassandra + RabbitMQ + Swift + ElasticSearch) —>
> Clustered
> * (Guice + Cassandra + ElasticSearch) —> Advanced
> * (JPA + Lucene) —> Basic
Is "Distributed" to ambiguous for you (instead of Clustered)?
> (Other ideas most welcome!)
>
> The explanation would look more like this (i.e. reverse the current
> order):
>
> * James Clustered Profile
> - For experts only
> - Used for large-scale clustered deployments
> - Most feature-packed and performant, but also the most complex
> installation
> - Uses Cassandra, RabbitMQ, Swift, and ElasticSearch behind the
> scenes
We support S3 too and we'll probably talk to Swift via S3 protocol
soon. Also, more people understand S3 than Swift or even Object
Storage. I would than replace Swift with S3 in that description.
> * James Advanced Profile
> - For experienced operators only
> - Used for mid-sized to large deployments
> - Some additional features and quite performant, but somewhat
> complex installation
> - Uses Cassandra and ElasticSearch behind the scenes
>
> * James Basic Profile
> - Used for smaller deployments
> - Appropriate for most operators
> - Best choice for most installations (if you are not sure, choose
> this one!)
> - Fewer functions and less performant, but simpler installation
> and suitable for most cases
> - Uses JPA + Lucene behind the scenes
I really don't like using JPA in product/profile description. I'd
rather describe where data is store.
As you may have read, we have one product/profile using derby (embeded
database using local filesystem) and another using mariadb/myql.
> People who don’t really know what they are doing should be encouraged
> towards the simpler Profile. When the user/operator is more
> confident, then they can start to look into the more complex
> Profiles.
Agree
> It would be great to also have a “minimal” Profile that uses the file
> system and a minimal number of dependencies, if possible.
It's JPA with derby.
> The idea of changing the name is to make it easier to understand the
> purpose, and make the list easier to grok.
>
>
> > > 2. How do these get wired / configured? Is there anything I need
> > > to
> > > do? If yes, what? If no, how does that work?
> >
> > For Guice products, all important component are hardcoded for each
> > product. You still have some choices you can make in configuration
> > like
> > choosing the object-storage technology you want.
> >
> > For Spring, there's a lot you can do but I'd rather not document
> > that
> > and let people who understand Spring deal with it, at least for
> > now.
>
> In that case, for the User Manual, I would suggest that we completely
> discard any mention of Guice and Spring. Of course these can be
> mentioned in the “Operator” and “Developer” sections.
Fully agree. The reason with kept it is for distinguish from existing
"spring" version.
[...]
> If these are “supported”, it may be nice to be able to expose them to
> the users, or at least maybe one more “Minimal” Profile as I mention
> above. What do you think?
>
Yes, it's the list of product/profile we want to expose to the user.
The minimal profile is actual jpa+derby as said above.
Thank you for the questions and proposals.
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: James configurations
Posted by David Leangen <ap...@leangen.net>.
Hi Matthieu,
Thank you for the great comments! My replies inline.
>> 1. What are these configurations for?
>
> It's related to our product strategy.
[snip]
> a product is a solution that we package and has been tested to work. A user can expect the community to care about problems on these products if any and have support.
Ok, that makes sense. Thank you.
My first follow-up question:
* Is the name “product” set in stone? Would it be possible to call it a “profile” for example?
> The list of products is the one above (and some more, see
> https://github.com/apache/james-project/pull/188/files), and we keep
> the Spring support for the time being for existing users.
Ok, very nice!
>> Why would I want to choose one over another?
>
> Well, it really depends on what you want to do.
>
> * James with Guice + Cassandra + RabbitMQ + Swift + ElasticSearch
>
> is for large-scale clustered deployment
>
> * James with Guice + Cassandra + ElasticSearch
>
> is for medium-scale (no clustering support of James but
> scalability for Cassandra and ElasticSearch)
>
> * James with Guice + JPA + Lucene
>
> is for small-scale deployment as it store things in an RDBMS
> and index things in local Lucene files
>
> * Spring
>
> is here for legacy reasons
>
>> Why should I care?
>
> Because you have different cost/benefits trade-off for each solution.
> You probably want to choose the right technology for your problem.
Ok, that makes sense.
I would like to change the wording for the User Manual in order to expose the fewest concepts as possible, or at least to be able to spoon feed the users better, rather than making them try to swallow too much all at once.
I would like to rename these Products / Deployments / Profiles to something like:
* (Guice + Cassandra + RabbitMQ + Swift + ElasticSearch) —> Clustered
* (Guice + Cassandra + ElasticSearch) —> Advanced
* (JPA + Lucene) —> Basic
(Other ideas most welcome!)
The explanation would look more like this (i.e. reverse the current order):
* James Clustered Profile
- For experts only
- Used for large-scale clustered deployments
- Most feature-packed and performant, but also the most complex installation
- Uses Cassandra, RabbitMQ, Swift, and ElasticSearch behind the scenes
* James Advanced Profile
- For experienced operators only
- Used for mid-sized to large deployments
- Some additional features and quite performant, but somewhat complex installation
- Uses Cassandra and ElasticSearch behind the scenes
* James Basic Profile
- Used for smaller deployments
- Appropriate for most operators
- Best choice for most installations (if you are not sure, choose this one!)
- Fewer functions and less performant, but simpler installation and suitable for most cases
- Uses JPA + Lucene behind the scenes
People who don’t really know what they are doing should be encouraged towards the simpler Profile. When the user/operator is more confident, then they can start to look into the more complex Profiles.
It would be great to also have a “minimal” Profile that uses the file system and a minimal number of dependencies, if possible.
The idea of changing the name is to make it easier to understand the purpose, and make the list easier to grok.
>> 2. How do these get wired / configured? Is there anything I need to
>> do? If yes, what? If no, how does that work?
>
> For Guice products, all important component are hardcoded for each
> product. You still have some choices you can make in configuration like
> choosing the object-storage technology you want.
>
> For Spring, there's a lot you can do but I'd rather not document that
> and let people who understand Spring deal with it, at least for now.
In that case, for the User Manual, I would suggest that we completely discard any mention of Guice and Spring. Of course these can be mentioned in the “Operator” and “Developer” sections.
By the way, it seems to me, as a newcomer, to be an unnecessary complication to have both Guice and Spring. Why both, and not just one? I can only guess that this is because of legacy and the way James was developed over time? Wouldn’t it be easier to use OSGi instead of both Guice and Spring? But yeah… that would be a lot of work to make the change. :-/ Ok, never mind.
>> 3. Are there any other possible configurations that are not in this
>> list?
>
> We discussed that at length here
> https://github.com/apache/james-project/pull/188/files if you want to
> have a look.
Ok, thanks.
If these are “supported”, it may be nice to be able to expose them to the users, or at least maybe one more “Minimal” Profile as I mention above. What do you think?
Cheers,
=David
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: James configurations
Posted by Matthieu Baechler <ma...@apache.org>.
Hi David,
On Sun, 2020-05-10 at 11:41 +0900, David Leangen wrote:
> Hello,
>
> Since I am very new to James, I have the advantage of looking at the
> available documents with fresh eyes. For that reason, I am currently
> working on trying to update the documentation, and have submitted a
> PR to get the ball rolling. [1]
>
> I will need some help for much of this work. I hope that you are
> willing to spare a few minutes to help me help the community.
>
> I am writing my questions here because I am trying to “develop” the
> documentation, but if you would like me to move to the user list, I
> could do that.
>
>
> Right now, I am interested in this section of the README.adoc file
> [2]:
>
>
> How to run James in Docker
> • Run James with Guice + Cassandra + RabbitMQ + Swift +
> ElasticSearch
> • Run James with Guice + Cassandra + ElasticSearch
> • Run James with Guice + JPA + Lucene
> • Run James with Spring + JPA
>
> As a new reader trying to figure out what is going on, I am already
> lost. To get me started, can you please tell me:
>
> 1. What are these configurations for?
It's related to our product strategy.
Some years ago, James had only Spring support.
For somebody to start with James, (s)he would have to choose the
implementations s(he) wants by editing xml files.
One had to choose which mailbox implementation (JPA for relational
database, Maildir for ... maildir format on local filesystem, and so
on), for user management, etc.
One problem was that some people didn't understand where their data was
stored.
Another one was that one could potentially use combination of
components that nobody ever tried and face problems nobody is willing
to solve.
So we decided to promote the concept of product: a product is a
solution that we package and has been tested to work. A user can expect
the community to care about problems on these products if any and have
support.
The list of products is the one above (and some more, see
https://github.com/apache/james-project/pull/188/files), and we keep
the Spring support for the time being for existing users.
> Why would I want to choose one over another?
Well, it really depends on what you want to do.
* James with Guice + Cassandra + RabbitMQ + Swift + ElasticSearch
is for large-scale clustered deployment
* James with Guice + Cassandra + ElasticSearch
is for medium-scale (no clustering support of James but
scalability for Cassandra and ElasticSearch)
* James with Guice + JPA + Lucene
is for small-scale deployment as it store things in an RDBMS
and index things in local Lucene files
* Spring
is here for legacy reasons
> Why should I care?
Because you have different cost/benefits trade-off for each solution.
You probably want to choose the right technology for your problem.
> 2. How do these get wired / configured? Is there anything I need to
> do? If yes, what? If no, how does that work?
For Guice products, all important component are hardcoded for each
product. You still have some choices you can make in configuration like
choosing the object-storage technology you want.
For Spring, there's a lot you can do but I'd rather not document that
and let people who understand Spring deal with it, at least for now.
> 3. Are there any other possible configurations that are not in this
> list?
>
We discussed that at length here
https://github.com/apache/james-project/pull/188/files if you want to
have a look.
Cheers,
--
Matthieu Baechler
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org