Thanks Benoit, very helpful! It does lead to more questions, though. :-)

> - **mailet** are separated in an effort to serve as a specification for...
> - **mailbox** as presented below is a storage service for the server….
> - **protocols** is an effort to provide mail protocol utility for...
> I hope I provided some context about the project structure…
> I would call the core component the **mailet container**...


Yes, indeed! Let me try to rephrase this in my own wording to test if I 
understood. I’ll use the Servlet spec as an analogy, because what you write 
about Mailet and protocols triggered that comparison in my mind.

If we use the analogy of the HTTP<—>Servlets, then in this case there would be 
a similar relationship between for example IMAP<—>Mailet.

A gross simplification of the essence of a generic Servlet is:

```
public interface Servlet {
  void service(Request req, Response rsp) throws ServletException;
}
```

More specific to the HTTP protocol is:

```
public class HttpServlet {
  public void get(HttpRequest req, HttpResponse rsp) throws ServletException;
  public void put(HttpRequest req, HttpResponse rsp) throws ServletException;
  public void post(HttpRequest req, HttpResponse rsp) throws ServletException;
  public void delete(HttpRequest req, HttpResponse rsp) throws ServletException;
  public void etc(HttpRequest req, HttpResponse rsp) throws ServletException;
}
```


So for a Mailet, the idea would be:

```
public interface Mailet {
  void service(Request req, Response rsp) throws MailetException;
}
```

And for the IMAP protocol:

```
public class ImapMailet {
  public void doSomethingImapSpecific(IMAPRequest req, IMAPResponse rsp) throws 
MailetException;
}
```

However, the actual generic signature is:

```
void service(Mail mail) throws MessagingException;
```

(By the way, does this mean that the Mail is mutable and that the service 
method creates a side-effect by modifying the Mail object??)

Is the analogy something along the right lines? So for example: "Tomcat is to 
the Servlet spec as James is to the Mailet spec"??


Even if the analogy makes sense, the one big difference is that Servlets are 
stateless, but emails are not, so as you pointed out it needs the concept of 
Mailboxes for storage. 


>> * Mime4j
>> * jSieve
>> * jSFP
>> * jDKIM
> 
> I would call them "external librairies".

To me, according to the vocabulary that I am used to (meaning that I am not 
claiming to be “right”, just that this is my experience), a "library" is 
something that gets embedded into a "component". Both are just ways of 
packaging up code, but the library is both “hidden” and "disposable" (meaning 
that it is just part of the implementation and is not seem from the outside, 
nor cared about), while the "component" is something that is actually seen from 
the outside and worth understanding in order to understand the entire system.

If users or maybe even developers of James don't have to care about Mime4j and 
it can be hidden away, then I would agree that it is a library. It would just 
be part of some other components, and would only come into scope when 
developing that component. So for this documentation project, I probably 
wouldn't even have to mention it at all.

Or in other words, only one of the following is correct:

 * These concepts are understood internally by James core, but the 
implementation code is provided by these libraries and does not need to be 
exposed to the outside

OR

 * These concepts are not understood by the James core, so both the concepts 
(API) and the implementation are provided by these external projects



>> Administration
>> ------------------------------------
>> The port is the “Admin API”. There are 3 adapters: JMX, REST, and CLI.
> 
> A user could be loading additional webadmin routes (~plugin)

Sorry, I don’t understand this statement…



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

Ok. As for the rest of of the details you provided about the mailbox-api, I’ll 
get back to that later.


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

But you already wrote above that it is Mailbox that describes storage in the 
context of a Mailet-based system like James.

If something is being stored, then it must be because the concept is known to 
the core part of the system. Or are you saying that the core offers a generic 
“data storage” service to outside components that want to use it? So it is some 
generic storage service like labels in Kubernetes that is used however external 
libraries want to use it?


> * mailQueue is clearly a central component is James (as in any SMTP server)

But I have understood from all of the documentation and our emails so far that 
"SMTP is just a protocol". It sounds like there is more to it than just a 
protocol, then. There are expectations about behaviour and the services offered 
by the system.


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

How is this related to Mailbox? Does Mailbox use the blob store (so Mailbox is 
like the Aggregate Root if this were a DDD concept)? Or does Mailbox get 
bypassed, so that actually storage is more like Mailbox+blobstore?


> * mail-repository allows storage of email with their processing context

So you mean it adds extended functionality to a Mailbox? I’m not entirely sure 
I understand this statement.


> * sieve script storage (nowadays part of data-api)

Right, but I already understood that sieve is “external”, so now I am confused.



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

So there is a core concept of a “task”? Is this a cross-cutting concern that is 
known by all components of the system? So for example the Mailbox admin knows 
that “Move Mailbox” is a task, and therefore it can be scheduled?

Can you please explain more about what a “task” is in James, and how it is used?


Cheers,
=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