I remember at some point in James' codebase there was a set of interfaces.
And if you implemented them you could fully determine how James persists
data.
In this case storing to any amount of databases with your
organisation-specific criteria would be no problem.
You would just implement the storage related interfaces in any way you like.
If I wish to implement a custom backend is it enough to provide
implementations to all interfaces under org.apache.james.mailbox package?
- Rami
On 09-May-18 09:56, Ioan Eugen Stan wrote:
Hi,
I think id does make sense to have such a functionality. No reason to
keep archived emails in the main storage if hey are rarely accessed. Not
sure on what solution to adopt as there are many possible ways to
achieve this.
One thing that I am thinking of is to provide a Composite Mailbox
implementation.
A rough sketch is bellow:
This composite mailbox implementation could delegate actual processing
to a couple of implementations. Each implementation could manage a group
of folders.
This solution could solve this use case by:
- keep normal folders inside a database using jpa implementation
- keep archived emails in a Maildir or S3 storage etc, possibly on
slower, less expensive systems.
I haven't given a lot of thought to this so I'm not sure if it is even
possible at the moment, but I think the pattern has some merit.
Regards,
Eugen
On 09.05.2018 07:46, Benoit Tellier wrote:
Hi Jerry,
There is currently no solution to do what you describe. There is no
"custom storage treatment" for archived mails.
I did not address nor faced this problem, thus can not really help you.
Cheers,
Benoit Tellier
Le 09/05/2018 à 02:08, Jerry Malcolm a écrit :
I realize this is a completely off-the-wall question... but has there
been any discussion about breaking the JAMES db into multiple
databases? I have a bunch of clients, each with a bunch of accounts.
And they all want to archive all of their mail and be able to access it
through the same mail client. As the years go by, the db just keeps
growing and growing. This became acutely obvious when I was recently
forced by my server provider to migrate to newer hardware, and I
realized I had to have mail down for a long time while I transferred a
60gB+ file across a slow connection to the new server. The db size is
also making daily backups a problem.
The reality is that 90% of the mail is archived into 'year' folders for
each of the accounts which are basically "read-only" now. Only a
relatively small amount of mail is truly in dynamically updated
folders. If there was a way to store "/archives/2002" folders through
"/archives/2017" folders in one db and all of the other folders in
another db, it would make backup and migration a much simpler task.
Ok, I'm pretty sure that isn't in the immediate plan. But just let me
put my vote in. Alternatively, is there any alternative to having one
ever-growing mail db? Is there some trick with the db server that can
present one logical db from multiple db files? (I know a lot about
databases... but there's still a bunch I don't know). Has anyone else
faced/addressed this problem? Or is the answer to just live with it?
Thanks.
Jerry
---------------------------------------------------------------------
To unsubscribe, e-mail: server-user-unsubscr...@james.apache.org
For additional commands, e-mail: server-user-h...@james.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: server-user-unsubscr...@james.apache.org
For additional commands, e-mail: server-user-h...@james.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: server-user-unsubscr...@james.apache.org
For additional commands, e-mail: server-user-h...@james.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: server-user-unsubscr...@james.apache.org
For additional commands, e-mail: server-user-h...@james.apache.org
