Joachim Draeger wrote:
Hi all!
I guess it is wished that the API for just accessing user inboxes should
stay as easy as possible.
That's why I'm proposing a separate Interface that only contains core
functionalities.
Just like addUser has been moved from James class to UsersRepository,
getUserInbox could be moved to MailboxManagerProvider (alias
MailboxService):
package org.apache.james.mailboxservice;
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. 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.
interface BasicMailbox {
/** @return the key */
String store(MimeMessage message) throws MessagingException;
/** @return keys */
Collection list() throws MessagingException;
MimeMessage retrieve(String key);
/**
* key changes by updating
* @param key the current key
* @return the new key
*/
String update(String key, MimeMessage message)
throws MessagingException;
void remove(String key)
throws MessagingException;
}
interface BasicMailboxSession extends BasicMailbox, MailboxSession {}
public interface MailboxSession {
public void close();
public boolean isWriteable();
}
Cosmetic: "BasicMailboxSession" is awful for an interface name (Basic
make me think of a basic *implementation* of the MailboxSession interface).
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)
The main differences to current MailRepository are:
* keys are generated by mailbox
+1
* separate store/update
+1
* 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.
* 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?
(I will elaborate on this in another leaf of this thread, currently
evolving)
Okay there is one point that is a bit more difficult:
ToRepository Mailet, which accepts a url.
It is used for mail that is not delivered to a user like spam or mail
that can't be delivered.
I guess the ability to put this repositories where ever one wants is
quite popular.
Maybe we could use a logical #system name space here like #system.spam
or #system.address-error.
For example this could be mapped like: #system.* -> file:/var/mail/*
Well, this starts fitting in a different idea we had in past: virtual
repository tree and mount points.
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.
Roadmap:
1. discussion
2. vote
3. deprecate MailRepository and James.getUserInbox() (not to break
backward compatibility)
4. provide BasicMailbox wrappers around MailRepository
5. refactor current components to use MailboxService.
What do you think?
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.
Stefano
Joachim
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.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
