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