Hello,
For me "server" is nice to describe a particular packaged James setup.
The term might me a little too much generic, but if you prefer it above
"flavor" or "product" or "profile", why not.
On the other hand, when you customize a particular "server" (to use an
LDAP user repository for example instead of a Database user repository),
it's not a different flavor. It's the same server, with just some
specific configuration. So for me it's then useless to introduce a new
term here (flavor) while the admin will only configure this particular
James server.
Regards,
Raphaël.
Le 04/06/2020 à 08:06, Tellier Benoit a écrit :
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
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org
