Re: Product vs. Profile
Hi, I think it is best to let others decide, but I wanted to respond just to this part: > As such the JAMES project would ship a set of servers: > - The "demo" server > - The "simple" server > - The "distributed" server I don’t recall how we got there, but the current docs use: - Demo Server - Local Server - Redundant Server - Distributed Server Do you think this should be changed? Cheers, =David - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
Re: Product vs. Profile
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
Re: Product vs. Profile
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
Re: Product vs. Profile
> 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
Re: Product vs. Profile
Hi Raphaël, > Yes, that's the global idea. But we differ about what is the "thing". For me > the "thing", or the product is James, a mail server where you can easily > configure a specific business logic. So the product serves different > protocols: SMTP, IMAP, JMAP, etc., can be managed (CLI / webadmin) and of > course can store data. > > Then comes the flavors: the one-node DB flavor, the only SMTP flavor, the > distributed flavor, etc. Your explanation makes sense to me, but I am not qualified to judge if it is the “right” thing or not, so I’ll let others comment. It sounds like your opinion differs from those who would call these “products”. I’ll have to let you guys duke it out. :-) I can say that from a beginner’s perspective, so far I do not find it “easy” to configure James. But perhaps I will get there yet, and hopefully the new documentation will help. >> So maybe “RDB storage” vs. “filesystem storage” could be different flavors >> of the “Basic Server”?? I.e. they both have the same objective and are the >> same “thing", but with a small variant that is likely a result of personal >> preference. > > > We cannot configure "Basic server" to have so different implementations. And > I think we don't want, as we cannot say that the "RDB storage" implementation > works in a same way than the "filesystem storage". > > Flavors can anyway be configured for some needs, for example the > "Distributed"/"Advanced" flavor can be configured to have a swift object > storage or a s3 object storage. The user repository could be configured to be > local of the flavor (DB / Cassandra) or based on LDAP. > > Does it makes sense? Yes and no. 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. > But maybe then the name of the flavors should not be Minimal/Basic/Advanced, > but more based on what value they bring to the user, for example: > Local/Redundant/Distributed. Very good idea!! That is the missing concept I was looking for. Thanks! Cheers, =David - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
Re: Product vs. Profile
Hello David, Le 28/05/2020 à 07:55, David Leangen a écrit : Hello Raphaël, Someone (aka Michael Bailly) suggested "Flavor" instead of "Product". I also think it's a nice way to speak about a product already configured to match some specific needs. Yes, “flavor” could be a good concept. I think that is for variations of a “thing” that accomplish mostly the same goal, but with a “small” variation. Yes, that's the global idea. But we differ about what is the "thing". For me the "thing", or the product is James, a mail server where you can easily configure a specific business logic. So the product serves different protocols: SMTP, IMAP, JMAP, etc., can be managed (CLI / webadmin) and of course can store data. Then comes the flavors: the one-node DB flavor, the only SMTP flavor, the distributed flavor, etc. So for example “ice cream” and “candy bars” are not different flavors, they are different types of sweets. But vanilla and chocolate can be flavors of ice cream, which is the same “thing". So maybe “RDB storage” vs. “filesystem storage” could be different flavors of the “Basic Server”?? I.e. they both have the same objective and are the same “thing", but with a small variant that is likely a result of personal preference. We cannot configure "Basic server" to have so different implementations. And I think we don't want, as we cannot say that the "RDB storage" implementation works in a same way than the "filesystem storage". Flavors can anyway be configured for some needs, for example the "Distributed"/"Advanced" flavor can be configured to have a swift object storage or a s3 object storage. The user repository could be configured to be local of the flavor (DB / Cassandra) or based on LDAP. Does it makes sense? But maybe then the name of the flavors should not be Minimal/Basic/Advanced, but more based on what value they bring to the user, for example: Local/Redundant/Distributed. By the way, for now in the docs I am just calling these “Servers” (i.e. neither “products” nor “profiles”). What do you think? My intent was to remove the ambiguity of products and profiles. The product would be James, a mail server. The flavor would be the declination of this product to fit different deployment needs. Regards, Raphaël. - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
Re: Product vs. Profile
Hello Raphaël, > Someone (aka Michael Bailly) suggested "Flavor" instead of "Product". I also > think it's a nice way to speak about a product already configured to match > some specific needs. Yes, “flavor” could be a good concept. I think that is for variations of a “thing” that accomplish mostly the same goal, but with a “small” variation. So for example “ice cream” and “candy bars” are not different flavors, they are different types of sweets. But vanilla and chocolate can be flavors of ice cream, which is the same “thing". So maybe “RDB storage” vs. “filesystem storage” could be different flavors of the “Basic Server”?? I.e. they both have the same objective and are the same “thing", but with a small variant that is likely a result of personal preference. By the way, for now in the docs I am just calling these “Servers” (i.e. neither “products” nor “profiles”). 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
Re: Product vs. Profile
Hello, Someone (aka Michael Bailly) suggested "Flavor" instead of "Product". I also think it's a nice way to speak about a product already configured to match some specific needs. Regards, Raphaël. Le 14/05/2020 à 13:52, David Leangen a écrit : Hello! While writing the documentation, I came across a term for which I would like to propose a change. Benoit asked that we hold a discussion here before making a final decision. I am proposing that we change “Product” (as in for example the "James with Guice + Cassandra + RabbitMQ + Swift + ElasticSearch **Product**”) to “Profile”. At the same time, I am also proposing some more general names. For example, the above "James with Guice + Cassandra + RabbitMQ + Swift + ElasticSearch **Product**” would become the “James Distributed Profile”. The explanation I gave previously for my issue with “product" was: Personally, I have a problem with "product”. […] I tend to think of a "product" as something a little different than what is intended here. Mainly, "product" seems to me to have a very commercial connotation in English. I think that is not what is intended here. Secondly, I feel that "product" for the average person probably refers to "Apache James" itself. If anything, these would be more like "sub-products" to me. “Profile” seems a much better fit, if you are willing to make this change. 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
