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-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org

Reply via email to