Details
-
Task
-
Status: Closed
-
Major
-
Resolution: Fixed
-
3.3.0
-
None
-
None
Description
In order to improve overall James development experience, I propose to do a bit of post 3.3.0 cleanup.
The proposal is to mark the given components as deprecated now, then, if no contributor shows up and give some love to these components, remove it after 3.4.0 release.
An associated vote will be started on the mailing list.
Here are the rationals:
- Some components are not exposed to end users and affect our ability to refactor code.
- These components do not receive contributions
- These components are not well enough tested
- We introduced some components that are better at performing that very task
The components are:
mailbox
- mailbox/cache
Unused, not tested, low code quality
End user will not be affected by this removal
server/data
- SieveDefaultRepository
Read the filesystem to retrieve sieve scripts, read only, one file per user
This does not support sieve script management and rtequires dropping manually the filesystem
Migration strategy: use SieveFileRepository & CLI to upload scripts
- MBoxFileRepository
Already deprecated, will target removal after 3.4.0
Use FileMailRepository instead. Data migration can be done with reprocessing + specific configuration
- JDBCRecipientRewriteTable
Already deprecated, will target removal after 3.4.0
Use another RRT implementation
- AbstractJdbcUsersRepository DefaultUsersJdbcRepository & JamesUsersJdbcRepository
Already deprecated, will target removal after 3.4.0
Use another UsersRepository implementation
mailets
Note: these mailets are leveraging some storage capabilities of mailbox or server/data.
- AbstractRecipientRewriteTable
Already deprecated, will target removal after 3.4.0
The mailet is responsible for the rule storage. No tests.
Note that this would allow removing JDBCRecipientRewriteTable and XMLRecipientRewriteTable.
Migration plan: add the rules in the standard RRT and use the classic RRT mailet.
- JDBCAlias
Already deprecated, will target removal after 3.4.0
This mailet does the RRT. No tests.
Migration plan: add the rules in the standard RRT and use the classic RRT mailet.
- UsersRepositoryAliasingForwarding
Already deprecated, will target removal after 3.4.0
This buggy mailet expects the UsersRepository to be also a RecipientRewriteTable. Hopefully, we have no such freaks.
Otherwise behaves as the classic RRT mailet.
Migration: Replace in the configuration by the classic RRT mailet
- MailboxQuotaFixed, AbstractStorageQuota, AbstractQuotaMatcher
Not using the quota API, these matchers do full inbox scans on each processed email.
It adds confiusion with the non-experimental well tests IsOverQuota matcher, relying on the mailbox quota system.
No test, big hierarchy
Migration plan: Use IsOverQuota + quota APIs