Hello Eugen, Thanks for the reply.
I settled myself the objective to better document what we, as part of the James project commit to deliver. This email thread go in the right direction. I extracted it as it is no longer related to Scala usage, but higher level. Original thread: https://www.mail-archive.com/server-dev@james.apache.org/msg66332.html Le 12/06/2020 à 15:29, Eugen Stan a écrit : > Hi, > > Please use Eugen. That is my given name. Stan is my family name. > > La 11.06.2020 11:27, Tellier Benoit a scris: >> On 10/06/2020 15:19, Eugen Stan wrote: >>> I'm mostly referring to libraries. Having a library bring a dependency >>> like scala is a no-no on my part. >>> >>> Ideally the lower parts of James should not bring any dependencies. >>> Guava is also big and I would like to see that gone as well. >>> >>> [...] >> Hello Stan, >> >> It is unclear to me what you actually call a library. >> >> Could you provide us with an explanation? Maybe with a list of what you >> consider being libraries within the James project? >> >> I think sharing your thoughts here would help reaching a common vision. > > Sure. I'll give it a try. My version of a library definition is: > > "A library is a piece of code that is designed to used by other pieces > of code (libraries or applications). > > It encapsulates some behaviors that are specific to an area. > > It's designed to be reused. > > It targets developers." I think we miss the "externally used" aspect in your definition. This external, uncontrolled usage makes the difference in term of stability, and dependency requirements. (It is easy to align dependencies / perform refactoring within a single code base, and rely on compilation or automated tests to catch mistakes). I would add "a library have a well identified purpose". > > > Examples of libraries from James: > > - mime4j +1 > > - the mailbox implementations (More about that below...) > > - the protocol implementations: smtp, lmtp, etc I would tend to agree, I already saw some protocols-smtp outside of the James code base (copied however) - but would be unable to recall where, sorry @mbaechler. > > There can be libraries internal to a project and not very useful outside > of the project, because they are specific. Here I disagree. As other people are supposed to use them, we should expect them to be useful. Otherwise we are maintaining things for nothing. > > I think james-core fits this profile and some others. IMO james-core currently mixes 2 concerns: - filesystem / configuration - javax.mail utilities Maybe we should consider splitting it in two. > > Libraries can depend on internal libraries - since they form a closed > world (of course the other libraries should have no or few external > dependencies). > > > For an application: > > Something that is meant to be used "as is" by end users (download and run). > > It can be customized and tweaked by end user (branding, change > implementations, etc). > > Examples of applications in James: > > - James Server - all the flavors > > - mbox parser > > - mpt Maybe we should have a top level list of all applications. And detail their level of maturity, and maybe also the level of support/efforts we are willing to commit to it. Maybe a topic for another thread... Also, I'm expecting applications to be downloadable from James website. > Please keep in mind that a single piece of source code can be packaged > in many forms for delivery. > > Taking the mailbox import/export functionality as an example we could > have it part of the James server and we could have it packaged as a CLI > application that is distributed separately . > > The core functionality of import/export in the above examples is the > same, however each use case comes with it's specifics and might (will) > bring in other dependencies and steps: the CLI will probably require an > argument parsing library. The binaries for the CLI could be built for > arm64, amd64, etc. > > When talking about libraries, we don't usually discuss all those points. > > Libraries should be small and focused. They should have minimal / no > dependencies (maybe logging). > > Libraries can be used to compose one or many applications (via guice > modules or spring beans) as we do for James Server. > > IMO the composability part should not be in the library (no spring > annotations like @Component or @Autowired, probably not @Inject either). > > Libraries following the above guidelines/rules are usually very stable > and very easy to upgrade. We should be in my opinion very careful not mixing "Components" offering services that can be reused within the James project eco-system, and a library. Stability and very low dependency count come with a cost that we can't pay for the entire code-base. We should clearly decide where it makes sense and where it do not. To take your above example, mailbox/export is implemented with limited dependencies in an isolated maven module. We can package it behind a WebAdmin REST endpoint, or behind a CLI easily, given that it has a well defined interface. As there is no expected nor supported external uses we don't need to fear "dependency clashes" nor be "interface stability / versioning zealots". (I agree API-stability + zero-dependencies perfectly makes sense for MIME4J, JSPF, JSIEVE, JDKIM, and maybe also for our MDN parser library that could be branded as JMDN once stable ;-) ) > > They compose easily. > > > Please share your feedback on this. Regarding MAILBOX, I am unaware of external usages, and I would more tend to think of it as a component of James server used for storing mails. The API is not stable, basic bugfixes, or feature implementations requires frequent API re-deasign. Not to be speaking of performance issue / reactive code adoption. Also the MAILBOX API is historically oriented toward IMAP usages, and other usages like JMAP are hard to implement with it. Considering MAILBOX as a generic purpose email storage library would make maintaining the James servers a pain. What I would propose here is: - Identify areas of MAILBOX qualifying for "generic purpose library" (I think a subset of the MAILDIR implementation qualifies, as it could unlock maildir format manipulation in Java). - Move /mailbox folder into /server/mailbox to reflect the fact that MAILBOX is a component of the JAMES server. - Close the MAILBOX bugtracker, open some for the subprojects that makes sense. Hopefully we would then be able to simplify the project structure: - Move back /backends-common into /server - Idem for some server components like event-sourcing, james-json, javax-mail-extension... Maybe once we reach a performant, feature complete, stable email server we could re-consider MAILBOX as a standalone library. I don't think it makes much sense today and the cost is high. (Maybe that should be a separate email thread). > > The list of libraries is not complete. We maybe should invest in a complete list and clearly document it in the website first page. > > > Regards, > Cheers, Benoit --------------------------------------------------------------------- To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
