Hi Matthieu,
> We somehow already analyzed that topic in the past and this is what we came > to : > > 1. James is a mail server that can integrate your business logic > 2. James is a mail framework : you can build you application and specific > needs into James > 3. James is a set of libraries: you can take parts of James and build > something that is not a mail server with it This actually sounds very similar to: >> James as a “solution” to that problem in one of 3 ways: >> >> 1. Out-of-the-box >> 2. Assembled >> 3. Customized I am not putting #3 on your list into scope at this time, though. I do not think I’ll have time for that. > So to answer to what you propose, I really think we did a mistake at trying > to do these 3 things. Everytime I open a web page that say very general > things about a software that try to do too much, I just go away. Yes, I agree, and I do the same thing. If a website describes something in an abstract way, and I am not able to quickly figure out how to apply it to my objectives, I quickly lose interest. I would even say that you and I are not alone: most people act that way IMO. That is indeed one of the objectives that I am trying to accomplish, i.e. *not* to make documentation that is not practical. The idea is: >> 1. Out-of-the-box The wording “out-of-the-box” usually implies that you just need to plug it in, and it should work. This should be good for those who are impatient. They should be able to get up and running very quickly. If indeed they can get set up with a working server quickly, then the objective would be accomplished, and the user would be satisfied. I have not yet been able to test if this is actually the case or not. If it’s not currently possible, then I would argue that even more urgently than fixing documentation, this should be the primary short-term objective of the entire team right now. >> 2. Assembled If we can show concretely (with a few examples) how “easy” it is to assemble a James product, then on the contrary, I think it would be very interesting. >> 3. Customized Again for those who need it, if we can show concretely (with some examples) how “easy” it is to customize a James-based product, then it would be interesting. But the key is not the wording, the key is the ease with which it can be done. If there are too many technical hurdles, then THAT is the barrier IMO. I cannot judge because I am still not there yet. > It think James should be promoted as a flexible Mail Server. Other usages > will emerge if we reach that goal. > It's why I prefer "Mail Server”. Yes, that is indeed true. But aren’t the other parts also important? > Another point is "Enterprise": I think that any "Enterprise" software is > suspicious at best. Free Software should empower anybody. So I would > propose to drop that word. > > Finally, I think that Java is not a selling point any longer, the JVM is. > So I would rather propose "JVM Mail Server”. Both of these points are good points…. but then we’ll have to either find a new name for the project, or find different words that match “James”. Or maybe drop James as an acronym and just come up with a completely different story about why the project is called “James”. > Coming back to the documentation: James is pointless without (at least) > Mailets. I would focus the documentation mainly on the Mail Server target > and would promote customization as a top-level concept of it. Ok, point taken about Mailets. (Half-jokingly) how about: JVM Asynchronous Mailet Event Stream Joke aside, I will refine my approach a bit, but unless I am misunderstanding you, it still sounds to me like this is generally the right direction to take. Hopefully once I proceed a bit further it should become a little clearer. Cheers, =David --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
