Thanks a lot for the additional context, benoit

I have added that as a comment on the issue to make it more readily
discoverable. When we reach cleanup phase, I'll try to add some
documentation to the interfaces in the code.

Cheers
jean

> One case is "it was mentioned in the server configuration, and no longer
> is".
>

> Without such persistence you could not, for instance, reprocess mail
> repositories that you had been using.
>
> --------------
>
> An other case is "parametric mail repository" ie cassandra://var/mail/
> customera.com/rejected
>
> One such exemple is Data Leak Prevention cf
> https://github.com/apache/james-project/tree/master/server/mailet/mailets/src/main/java/org/apache/james/transport/matchers/dlp
>
> And his friend
> https://github.com/apache/james-project/blob/master/server/mailet/mailets/src/main/java/org/apache/james/transport/mailets/ToSenderDomainRepository.java
>
> I might want to access a mail repository that exist, contains stuff, but
> is not provisionned localy because the James server I am using did not yet
> reject an email for this domain since it had been started.
>
> --------------
>
> Another thing is the difference between mailrepository URL / path (which I
> am not a fan of)
>
> The idea was not to leak through webadmin the underlying storage structure
>
> URL: cassandra://var/mail/error
> PATH: var/mail/error
>
> Then you need to do translation between the path and the URL, which is not
> trivial in face of several underlying storage technologies (jdbc + file for
> example)
>
> Even if there is a way to dynamically make james store mails in a mail
> repository that is not mentioned in the configuration, the in memory
> implementation will still register it when it is used.  I guess that only
> leaves discoverability of existing MailRepositoryUrls across restarts when
> an Url is not used much. That leaves me wondering what the actual use case
> is ...
>
> Well the one time I had to deal with mail repository with a customer,
> listing them was handy.
>
> That being said, I also share the feeling that "listing URLs in use"
> through MailRepositoryUrlStore might be overkill.
>
> Instead we could rely on each MailRepository implementation to list the
> URLs it do actually contain, thus drop MailRepositoryUrlStore alltogether,
> make it an implementation detail.
>
> We would get :
>   - MailRepositoryUrlSupplier interface with an implementation for each
> MailRepository implementation.
>   - Implementations can base decisions on their underlying storage thus
> removing the needs for additional metadata.
>
> I would support such a refactoring. One less Cassandra table makes me
> happy ;-)
>
>
>
>> Ideally MailRepositoryUrlStore should not have had been in the API.
>>
>
> Interesting, according to git history it was introduced by
> https://issues.apache.org/jira/browse/JAMES-2418 but that only says that
> the last point I mention above ( the discoverability part)  is needed but
> not why it is needed :D
>
> I hope I did get better at writting issues since then :-P
>
>
> cheers
> jean
>
>
> Cheers
>
>

Reply via email to