Hello Benoit, Thanks for your feedback.
I think it makes sense an we agree on a lot. Before moving the discussion forward let's make the inventory of libraries, and components as part of the documentation effort. We can work on a git branch in the docs area, sync on gitter for a quick review and come back with a proposal on the ML. I think the idea of splitting the concerns in core has merit and we should pursue it (I am not up to date with what is in core atm). Regarding the Mailbox API - I tend to agree, bet let's evaluate this again once the inventory is done and we have an overview. Regards, Eugen La 15.06.2020 14:58, Tellier Benoit a scris: > 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 > -- Eugen Stan +40720 898 747 / netdava.com
<<attachment: eugen_stan.vcf>>
signature.asc
Description: OpenPGP digital signature
