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.
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.
appendMessage(...): why does this interface take an additional Flags parameter? Aren't Flags already part of the MimeMessage structure?
I don't know. :-) Maybe it's reflecting the imap protocol and messages are stored with flags and to avoid an additional msg.setFlags() line, but I'm not sure.
Can you give me an explanation of name and fullname ? Sorry for my ignorance in IMAP :-(
My IMAP knowledge is not that substantiated, too. I guess fullname contains namespace information. name is just like "trash" or "drafts".
getFirstUnseen/getUnseenCount: is this user specific or a folder has the seen/unseen concept in a user-agnostic way?
As of my experience it's not user-agnostic. If anybody has open a message it is read.
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.
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
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 --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
