Stefano Bagnara schrieb:
Ok, I know I'm ignorant about IMAP. Sorry for so much questions!
No problem. :-)
KEY => A unique string that identify a single message in the repository:
persistent over sessions and restart, right?
Right. Like it's used for pop3.
UID => A unique number that identify a single message in the repository:
persistent over sessions and restart as long as UIDVALIDITY does not
change (can UIDVALIDITY be changed in the middle of a session?)
The more important point: the UID of an appended message has to be higher then
the one before.
Normally: UID=1 for the first Message, UID=2 for the second...
If there are uids 1,2,3 and 3 is deleted next appended is 4.
So you have to save the last appended uid somewhere.
Normally: UIDVALIDITY is created randomly at mailbox creation and never changes.
The client remembers UIDVALIDITY just to check if the UIDs it has seen in the
last sessions are still valid. If UIDVALIDITY has changed, the mailbox has been
probably deleted and recreated in the meantime.
MSN => Are temporary numbers having meanings only inside a given session
and uniquely associated to an underlying message (From my understanding
we cannot use UIDs as MSN because MSN must start with 1 and be a
complete sequence, is this right?).
Right. Even if a message gets externally deleted during the session, the numbers
have to be stable. Accessing the deleted message leads to an error.
So MSN is the message number that we also use when deleting messages by
message number in pop3.
Right. The concept is the same in IMAP, POP3 and JavaMail.
What about POP3 UIDL ? POP3 require persistent
keys: can we use UID or do we need KEYs for this?
I would like to understand the differences between UID and KEY and why
we need both. Can't we have one of them to implement the other?
KEY = POP3 UIDL is not required by IMAP.
An implementation that is based on UID can simply return a String representation
of the UID as the KEY.
The idea is that there may be repositories that don't support UIDs. (like todays
MessageRepositories or pure Maildir or MBox) They could at least provide keys by
a hash-sum.
Trying to access them by IMAP will raise an error.
Services that don't need UID capabilities (POP3) should always use KEYs so they
are able to access every Mailbox.
You always have to check things like: is the mailbox/message still there?
Maybe you have to reopen resources do hashing/cashing/parsing each
request...
You can't use a efficient SQL JOIN to fetch everything requested at once.
>
I noticed that you know mostly exactly what you want, e.g.: flags,
MimeMessage, Uid
So the backend *can* optimize this request to fetch everything at once.
And if you just want stream and flags, it should provide you with
stream and flags and not an all-purpose pseudo-light-weight
MimeMessage monster. ;-)
And not require you to do a request for every single item.
Can't we load everything but the mimemessage and keep the lazy loading
(MimeMessageSource) for this one?
Well a MimeMessage wouldn't be sufficient because it doesn't provide the uid or
the key. So you still need a result object.
MimeMessage is not extensible to provide additional attributes.
Is it so much work to load flags and uid for each message? Can't we do
this as a first step, and optimize things later?
I said "the backend *can* optimize the request". It does not forbid to load
everything at once. It does not forbid a lazy-loading MimeMessage.
But it does allow future optimizations.
2) Why Key/Flags/Msn/Uid/InternalDate are present in this interface
and, as an example, the From or the Subject is not there? Is this
related to what the IMAP protocol needs?
Oh yes, I thought about requesting headers without MimeMessage
monster, which maybe prepares resources to fetch a body stream... :-)
And no: key is what James needs, msn is what pop3+imap needs
And Yes, the rest is needed by IMAP.
Remember that we already have a MimeMessageWrapper: we could work on it
to know what is already loaded and what will need to load the headers or
the body. We already do something similar (We disabled the header
lazyness in 2.3 because of a bug that I have to investigate yet).
But all that is just more complicated then just telling the backend what you
would like to have.
A MessageResult is like a transaction: I don't have to fear that while dealing
with header lines the flags are getting deleted.
I'm not proposing to abandon MimeMessageWrapper and lazy-loading. I just can't
see the advantage to create a MimeMessage instance when I just want to have the
size.
To have a simple Bean to provide requested results is IMO the "cleanest"
solution.
Tell me something more about flags: can we simplify them as key=>value
as string=>string pairs? Or what else?
Instead of using the JavaMail Flags object? I don't like it so much either.
There is a defined set of flags (ANSWERED, DELETED, DRAFT, FLAGGED, SEEN,
RECENT)
So you could use bitwise integer values, boolean values, the names or
abbreviations.
Joachim
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
