Joachim Draeger wrote:
Is EventTriggerMailbox so important for basic proof of concept usage?
Is the whole "column selection" stuff (MessageResult) /
messageSetTypes a need for the basic repository interface?
Imap requires to deliver events about added/deleted and changed flags to
the client.
It would be possible to fake this events by just acknowledging actions
from the client by an appropriate event (this is what the client relies
on). But then you would have to manage workaround code.
Ok, I know I'm ignorant about IMAP. Sorry for so much questions!
I'm quite curious what you think about GeneralMessageSet and
MessageResult.
I started a JDBC prototype and found it quite handy.
Well, the only thing from M1 that could be postponed is the Javamail
proof-of-concept.
I don't like GeneralMessageSet becase:
1) Why do we need 3 types of keys (uid/msn/key) in a generic message
repository?
uid is required by imap. It's not trivial to implement uid capabilities
for all repository backends. You can translate uid to key (by just using
a string representation) but not vise versa.
So "clients" that don't need uid can access everything safely by key or
msn (message number).
Sorry but I'm slow to understand this.
KEY => A unique string that identify a single message in the repository:
persistent over sessions and restart, right?
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?)
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?).
So MSN is the message number that we also use when deleting messages by
message number in pop3. 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?
2) Imo the name is misleading: It is not a messageSet but a
SearchCriteria.
No, I don't think so. MSN to MSN, UID to UID, one key, is always an
exact definition of one or a range of messages.
Well, the fact that in some circumstances the search identify a specific
message or a specific set is not a problem: in fact when you run a
SELECT query and put a WHERE over the primary key you obtain a single
result, but it is anyway a QUERY to search records.
I prefer SearchCriteria, but this is not important at all: when we'll
have finished any other more important issue we'll discuss names ;-).
About MessageResult:
1) I think we should not reference Mail objects here, but only
MimeMessage objects (or even simple streams)
The idea is, when fetching from a spool you can get the Mail object. (if
you have requested it, if not possible, because it is not a spool, the
request for a Mail object had thrown an exception)
Imo we should remove this concept of SPOOL from the message repository.
If one will ever want to implement a spool repository based on a
messagereposirory it will have to store the Mail informations in a
messagerepository way (as Flags, or as custom MimeHeaders).
MessageRepository should not have dependencies on the Mail object.
And yes I just thought about including a stream as a result.
JavaMail for example is designed very object orientated, which is nice
for the client application.
For the backend it is horrible: You have to provide a light-weight
MimeMessage, that lazy-loads headers, flags, content, uid etc on demand.
We already have MimeMessageWrapper and we already delay the loading of
the message body by using a MimeMessageSource. The remaining data should
not be so much stuff to not be loaded everytime: isn't it?
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?
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?
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).
3) It seems TOO much IMAP oriented to not have Imap in the name: I
don't think that (as an example) an NNTPMessageRepository would need
Msn/Uid/Key/Flags and maybe it would need something else
NNTP uses article numbers. I just flew over the rfc and it talks about a
first and a last article number in the newsgroups so it is more uid like.
I guess NNTP would use message-ids as keys.
And when you access an NNTP repository through pop3/imap or custom code
in a mailet you could use msns.
I still don't have this msn/uid/key stuff clear in my mind...
That said I'm not against making an IMAP specific repository and I
always said that we should have a clear goal (Imap support) and create
a repository based on the specific needs of Imap (or better the
specific uses the most common Imap clients make of the Imap server).
msn/uid/flags, hierarchy like structure.
Ok, we need hierarchy like also in the core james, so we should find a
generic way to reference message repositories subtrees and to handle
virtual trees.
Tell me something more about flags: can we simplify them as key=>value
as string=>string pairs? Or what else?
<snipped some mailbox considerations: I'll reply to them later>
SpoolRepository and MessageRepositories will not be related any more.
I don't think that we'll ever need/want to write a
SpoolRepositoryAsMessageRepositoryWrapper.
I'm not up to date on the latest spool discussion. But for me a spool is
a MessageRepository with additional attributes and additional query
possibilities.
So if I would have written a great MessageRepository implementation I
could extend it to be able to work as an SpoolRepository.
But this is a bit out of scope for now. :-)
We'll try to refactor SpoolRepositories so that they *uses* a
MessageRepository for the MimeMessage but they only contains and spool
the Envelope part (the Mail object excluding the message): this would
mean that you can move a Mail object from a spool to another without
moving the related message (if both spool repositories uses the same
message repository).
To have something more concrete I just started to implement a Apache
Torque/JDBC based backend. It already helped me to find out a few
weak points of the design.
Great news!
Good choice with Torque as it is license compatible with James!
BTW I'm a bit disappointed. I tested Torque in the past and used it's
PHP clone Propel in a bigger project. And now I had to find out that
Propel has feature-overtook Torque. :-)
But I'm still convinced that even if there are not so many tables, it's
more agile not to have to write so much SQL and JDBC specific stuff.
It's easy to add/remove/rename attributes, create additional tables and
so on.
And although it's easier for me to develop on MySQL it should be easy to
switch to Derby.
In the future when performance matters it could be successive replaced
by optimized queries.
Joachim
I agree,
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
