Joachim Draeger wrote:
Stefano Bagnara wrote:
FolderAware: why does a mailRepository implements a FolderAware
interface that returns a Folder that is then incapsulated in a
JavaMailImapMailbox ? Can't we change the FolderAware to directly
return an ImapMailbox so we don't have direct access to the
underlying Javamail Folder interface at this level?
That is only an interim solution to allow access from the James side and
from the imap server side until we are sure how to design the new
MailStore. Then ImapMailbox and ImapStore interfaces will be obsolete
and James MailStore could be used directly.
Can you reply to the question itself? I understand your points but the
answer to the question will help me better understand if I learned
enough of that part ;-)
What is the relation between users and store/mailboxes ? Is it like
pop3 where we can keep it totally separated and simply have a method
to lookup a repository associated to a given user (to store mail in
localdelivery and to retrieve it in pop3server)?
I think yes by now. But for future enhancements we should keep in mind
the possibiltiy of implementing ACLs which would allow reading mailbox
of other users or group mailboxes.
But this would be a feature to implement when everything else works stable.
Ok, the important thing is that there is no direct association from a
mailbox to an user. Given a user we simply have to provide a method to
find the mailbox/mailboxes he can see.
To name them in a James style I would rename ImapMailbox to
MessageRepository. ImapStore functionality could be instead integrated
in our current Store.
I Agree. But I'm not sure if we should adopt it 1:1.
As you proposed we may introduce a "simple" MessageRepository with
limited capabilities and an ImapMessageRepository (or
HierarchicalMessageRepository, or AdvancedMessageRepository) exposing
the current functionalities of ImapMailbox.
getUidValidity, getUidNext, getMsn: what are intended for?
uidValidity is a (random or current time?) number that is generated when
the store is created. The first message stored get's the uid 1 the next
2. If the store is created again from scratch (maybe because of a system
crash) that uidvalidity changes and the client knows that he can't
depend on the now outdated uids. getUidNext is the uid the next new
message will get.
getMsn translates Uid to message number
Currently repositories do not have a persistent place to remember this
thing, but maybe we simply have to create an hash of the repository
configuration so it changes only when the repository configuration is
change. We probably don't need to make it to change in different
circumstances.
It is hard to foresee all the requirements without understanding the
whole thing.
I know I can't understand the whole thing if I don't soil my hands in
the mud...
I'm not deep enough, either. :-) Nobody is, so it's hard to make decisions.
Joachim
Let's follow the best path with what we currently have and let's hope
our instinct will bring us on the right way ;-)
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
