Hi all, It took me quite a while to put down my thoughts on the topic, here is what I think.
The JAMES project allows people to run "Servers". I currently really like the wording used in the documentation written by David on the topic. I don't see why we need a very abstract word like "product", "profile" or "flavor" to actually speak of a given server. As such the JAMES project would ship a set of servers: - The "demo" server - The "simple" server - The "distributed" server Removing a level of abstraction would enable people to actually better understand what we deliver. That being said, as described in [1] guice ADR, each "server" allows some controlled and (reasonably well tested) architecture customization, exposed by module choosing. I propose that we use the word "flavor" to speak about these customization of the architecture of a given server. We would be able to say: "I am using the distributed server with the LDAP flavor, and the object storage flavor." [1] https://github.com/apache/james-project/blob/master/src/adr/0036-against-use-of-conditional-statements-in-guice-modules.md Let me think about thoughts around this proposition. Cheers, Benoit On 28/05/2020 18:03, David Leangen wrote: >> To configure a storage component to use one type of another makes perfect >> sense to me. So to configure swift vs. s3 or DB vs. Cassandra, that makes >> good sense to me. But not to be able to configure filesystem vs. RDB does >> not make sense to me. > > Maybe I have reconciled this in my mind. > > You are likely referring not just to storage per se, but also to querying > (joins / folds) and indexing. Filesystem on its own does not have these > features. So for storing users etc. I think it makes sense. > > Perhaps a little less sense for Mailbox (according to my understanding), but > probably a topic for a separate thread… > > I think it’s ok to drop this topic for now. :-) > > > Cheers, > =David > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org > For additional commands, e-mail: server-dev-h...@james.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
