Stefano Bagnara schrieb:
Joachim Draeger wrote:
interface MailboxService {
BasicMailboxSession getBasicInboxSession(User user);
/** @param user the authorized User for checking credentials
@param mailboxName a logical/hierarchical mailbox name **/
BasicMailboxSession getBasicMailboxSession(
User user, String mailboxName);
}
What about isolating the "User => Inbox Repository" association to a
separate service?
We currently have this in the MailServer interface: "MailRepository
getUserInbox(String userName);" and this service is currently needed
by LocalDelivery and by POP3Server.
I think that if we want to "move" this service to some other existing
service it would be better to put this in the UsersRepository
interface than in a repository related service.
IMO it doesn't make sense to put it into the UsersRepository because
its a factory method that has to return different implementations for
different kind of backends. Choosing the right implementation is the job
of the MailboxService.
Maybe the best thing would be to add it to the UsersRepository but to
make it return the URL of the inbox repository and not the repository
itself.
That would make more sense to me. But I'm proposing not to use URLs.
An use case could be that the mailbox name differs from the username.
Maybe there could be other reasons to use an individual naming scheme.
I would prefer putting this into the User object, like
user.getInboxName(), but at the moment I don't think we need that.
Cosmetic: "BasicMailboxSession" is awful for an interface name (Basic
make me think of a basic *implementation* of the MailboxSession
interface).
I know that most of my working titles are awful. :-) They are grown or
have historic reasons.
At the end I find it difficult to choose new names. So I put out what I
have and wait for your suggestions.
Can you elaborate on the need of the 3 interfaces: BasicMailbox,
MailboxSession, BasicMailboxSession? Can't we start with a single
interface (BasicMailboxSession but renamed to something with no
"Basic" prefix, is my preference)
I tend to split all concerns into different interfaces at the beginning.
Some of them get discarded, some of them get merged.
In this case the idea is that e.g. ImapMailbox and B****Mailbox ;-)
don't inherit from SessionMailbox. directly to be able to provide one
ImapMailbox instance and a session wrapper.
But maybe it's obsolete.
* sessions have to be explicitly closed. (and not weak referenced and
_maybe_ gc'ed away)
+1 (you obtain a session and you release it calling its close, make
sense) Not sure wether the best way is to release the object to the
factory that produced it, or to simply "close" the object, but this is
a minor detail.
Thanks, I didn't think about that possibility. Maybe it enforces some
discipline to close the session "near" to where it has been created. And
not to close it just somewhere. Maybe it's an advantage not to have any
session methods in the interfaces.
* logical mailbox names that are mapped to physical backends
We already have something similar: we have urls that are mapped to
physical backends. What's the difference?
The URLs still depend on the backend. You can't browse them continuously.
BasicMailboxSession mailboxSession= mailboxService.
getBasicMailboxSession(User.SMTP, "#system.spam");
mailboxSession.store(aSpamMimeMessage);
mailboxSession.close();
I was just thinking that we need to do some operation that is not user
related so I thought we needed a "getMailboxSession(String url)"
without User. Maybe the User.SMTP thing (virtual user) could also be
used.
There could also be a User.ROOT that is allowed to do any modifications,
e.g. from the admin console.
An ACL implementation could disallow User.SMTP to deliver to a disabled
mailbox...
OK, but I think that 1 should include a few test in sandbox, because
problems with refactorings most time arise when you try to apply them.
I'm going to do so. It has many advantages.
PS: thank you for taking care of this proposal. I often thought to the
MessageRepository issue, but I never started it because it needs time
to collect everyone opinion and try to achieve a result in similar
threads.
For me it's a mile stone for the IMAP enabled backend development. It
wouldn't make sense to let the gap between IMAP backend and James
backend become too big.
Joachim
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
