Hello,

> If we can reach agreement on a definition for each of these, then we can 
> determine (1) how to document the concepts, and (2) if the code should be 
> refactored to better reflect these concepts.


Since I am starting to run out of time, I need to press forward. So for now 
since I have not heard any objections so far to my proposal, I will continue 
with the understanding that my definitions of “Core, “Port”, “Adapter”, and 
“External Device” are acceptable. These are **not** core domain concepts, but I 
am using them so that I can understand what the core concepts are, and because 
as Matthieu wrote James is based on this architecture in this thread: 
https://www.mail-archive.com/server-dev@james.apache.org/msg65809.html.

To try to understand what the Core domain concepts are, I initially thought 
Guice could be useful, but as Matthieu pointed out in that thread, that is not 
the ideal approach. This time I will use the top-level documentation and try to 
match it with the Maven modules.

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
 * Protocols

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”.

Another image is this one:

  https://james.apache.org/images/james-general-architecture.png

“James Core” is written in the middle. Although it is not immediately obvious, 
my interpretation is that the orange box represents the core (Server, Mailtets, 
Mailbox, Protocols), and the rest around the outside are the ports/adapters, 
which include:

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.


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.


Administration
------------------------------------
The port is the “Admin API”. There are 3 adapters: JMX, REST, and CLI.


Storage API
------------------------------------
This is actually a general term for 3 APIs:

 * Mailbox API
 * Search API
 * User API

Each implementation has an adapters for: Cassandra, MySQL, ElasticSearch …


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. :-(


I will proceed with this, and hope to hear comments soon.


Thanks!!
=David



---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org

Reply via email to