Joachim Draeger wrote:
I'll try to define a new James interface (MessageFolder or
MessageRepository) based on a subinterface of the Javamail Folder
interface. I'll start putting there all the commands we really use
from the Javamail folder.
And there you touched another big design deficiency of Javamail. There
isn't a Folder interface! That could really be a knock out against
Javamail because we would be very limited in inheritance. So I'm really
not sure about that. At the moment I propagate Javamail because it's
actually there and has a working implementation that fit's all needs of
imap.
The imap2 proposal already has own interfaces for ImapStore and
ImapMailbox (Folder). ImapMailbox is similar to Folder from Javamail.
I've created JavaMailImapStore and JavaMailImapMailbox which aren't much
more than wrapper classes. So the Javamail approach is enough capsulated.
However the final store will look like. It's like a prototype we can
learn from in the future.
Ok, I just looked at the ImapStore and ImapMailbox interfaces: If I
understood right those are the interfaces I intended we should have
created ;-)
I have a few questions:
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?
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)?
store(MailImpl): imho we should think at this new "repository" as a
Message repository and not Mail repository, so we can remove the
store(MailImpl) thing (as we would not store envelope informations
anyway) and only keep the appendMessage(MimeMessage).
appendMessage(...): why does this interface take an additional Flags
parameter? Aren't Flags already part of the MimeMessage structure?
Can you give me an explanation of name and fullname ? Sorry for my
ignorance in IMAP :-(
getFirstUnseen/getUnseenCount: is this user specific or a folder has the
seen/unseen concept in a user-agnostic way?
To name them in a James style I would rename ImapMailbox to
MessageRepository. ImapStore functionality could be instead integrated
in our current Store.
getUidValidity, getUidNext, getMsn: what are intended for?
copyMessage(long uid, ImapMailbox toMailbox): I always thought we need a
similar method but I always thought at it reversed:
copyMessage(ImapMailbox fromMailbox, long uid). I also thought that a
moveMessage would be useful to increase the optimization opportunities.
I just wanted to share a thought... nothing important right now.
This is a first step: I'll try to do this in the trunk in the next
weeks, then we'll move to the next issue.
The new interface will be experimental, but we discussed about this
repository change for years, we should put something in, and then
we'll refactor/tune it in future!
I'm pro starting a discussion about the backend. And it is always better
to have some experimental code than just talk about it. But I don't
think we should start implementing an own imap compatible store or
making irreversible design decisions at this time.
I agree! As you see I already had a lot of doubt to clear up before
starting anything.
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...
On the other hand i don't want to slow down. I actually love Java
because of refactoring.
Joachim
I hope I'll be helpful and not only someone that makes a lot of
questions and doesn't understand ;-)
I will have a lot of questions about the users also, as I already did a
few thoughts about usersrepository refactoring for James, and I'd like
to understand better the imap requirements for that. But more on this
later...
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
