Hello David, > I know you are all probably very busy, but to allow my contribution to be useful, it would be very nice to get comments on my journey so far. If I don’t document the “right” thing and run out of time, it would be a wasted opportunity. :-(
100% agree with that. Don't hesitate if you have questions on these topics. I tried to help you by providing as much details as I could think of. I believe what is important is defining: - Core components - Port for external devices - Port exposed to the user to extend James behavior, which I refer to as "Pugins." > One image I have seen is this one: > > https://james.apache.org/images/james-schema-subprojects.png > > It shows that the “central projects” are: > > * Server > * Mailets > * Mailbox > * Protocol While here I agree with the wording (project structure is mostly history related) it do partially reflect "system architecture". - **mailet** are separated in an effort to serve as a specification for mail processing. And "James" would tend to be "one of the implementation for running mailets". Maybe a question as a project would be to re-evaluate that goal: are mailets just a port for the Apache James server or used by other projects as a mail processing specification? - **mailbox** as presented below is a storage service for the server. Would it make sense out of the James server? - **protocols** is an effort to provide mail protocol utility for parsing, without hard dependency on server components, and without trasport implementation. **server/protocols** adapts **protocols** to the James components, relying on **netty** for transport. Stepping back, that goal is achieved for SMTP, however IMAP, POP3 and the like depends on "mailbox/api". I hope I provided some context about the project structure, and why it do not match the server architecture. Re-evaluating some of the above mentionned goals could be an interesting milestone for this PMC. > I am assuming that “central projects” is synonymous with “core” projects. So according to this diagramme, those projects are “core” projects. > > Other “important” projects are: > > * Mime4j > * jSieve > * jSFP > * jDKIM > > However, I will **not** address these yet, so I will completely ignore them for now. According to the image, they are clearly *not* core. They are noted as being “External Projects”. True. I would call them "external librairies". [...] > Mailet Containers > ------------------------------------ > Each Mailet is in itself an adapter, while the Mailet “specification” is the > port. The port is the interface/contract that is known and understood by both > the core and the outside world. Core doesn’t care what the Mailet does, so > long as each Mailet respects the contract, which is defined by the Mailet > “specification”. > > This is the main way that outside users can customize the behaviour of the > system. :+1: I would call the core component the **mailet container**. > > > Protocols > ------------------------------------ > Each protocol is also a port, and is known by both the core and the outside. > The shared knowledge is the external specification. > > Since these specifications are well-known, there are many “External Devices” > (applications) that implemented them. The SMTP protocols, LMTP protocol and POP3 protocols allow a user to load additional **ProtocolHandler** plugins, extending the behaviour of these protocols. > > > Administration > ------------------------------------ > The port is the “Admin API”. There are 3 adapters: JMX, REST, and CLI. A user could be loading additional webadmin routes (~plugin) > > > Storage API > ------------------------------------ > This is actually a general term for 3 APIs: > > * Mailbox API > * Search API Which is called "search API" is in my opinion a sub-part of the mailbox-api. That it is implemented via a sub-component is in my opinion an implementation detail of the mailbox component. The mailbox-api defines a plugin: the **mailbox listeners**. It allows to trigger asynchronous actions upon mailbox event. Also the **pre-deletion hooks** is a plugin that gets synchronously called before deletion happens, allowing extra actions to be taken. > * User API * data-api allow persistence of server data like users (above mentionned User API), domains, recipient rewriting rules. There might be some work to better name this component, and refine its boundaries. There is I think much more going on at the storage level. * mailQueue is clearly a central component is James (as in any SMTP server) * blob-store is a component for storing potentially large binary data. Other core-components implementations can rely on it to store (potentially large) binary data * mail-repository allows storage of email with their processing context * sieve script storage (nowadays part of data-api) Task manager --------------------- Allows to control and schedule long running tasks run by other components. We should, in my opinion, allow additional task registration via plugins. > Each implementation has an adapters for: Cassandra, MySQL, ElasticSearch > > > I will proceed with this, and hope to hear comments soon. I hope I did not loose myself too much into details, and again, don't hesitate if you have questions! > > > Thanks!! > =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
