Stefano Bagnara schrieb:
I think that even the single M1 step is too much stuff and we should
start with a much simpler set of interfaces.
In the last step I tried to breakup the interfaces in more parts, so
only a subset is needed.
But it won't work below MailboxRepository and ImapMailbox.
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.
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).
The idea is to use one getMessages(GeneralMessageSet) instead of
- getMessages(String key)
- getMessages(long fromUid, toUid)
- getMessages(int fromMsn, to Msn)
- setFlags(String key)
...
If you would an additional method for each return type, things explode:
- getFlags(key/uid/msn)
- getMimeMessage(key/uid/msn)
- getUid(key/msn)
....
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.
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)
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.
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.
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.
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.
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.
Either way I don't want to have IMAP specific stuff in the main
messagerepository interface and what you called Mailbox already has too
much stuff that is not needed by POP3.
Pop3 uses msn from GeneralMessageSet and not uid, (not key?).
Pop3 uses msn, key, size, MimeMessage from MessageResult and not uid,
internalDate, flags.
So a subset of GeneralMessageSet and MessageResult is needed, but that is how
they are intended.
Well, I'm have asked the same questions you have asked to myself and still
searching for an optimal solution, so I really appreciate discussion and
challenging. :-)
At the moment I don't think it makes sense to provide an additional
pop3-specific Pop3Mailbox interface that can only be queried by msn and only can
provide message, msn, size and key. And msn, size and key should be bundled in
one result type, not to have to make 3 queries or determine the size by fetching
the message object. (which is probably expensive)
So you would need a Pop3MessageResult and a ImapMessageResult (which extends
Pop3MessageResult).
ImapMailbox extends Pop3Mailbox.
What should ImapMailbox provide? A Pop3MessageResult that can be casted to an
ImapMessageResult? I don't like that.
Provide getPop3MessageResult and getImapMessageResult?
POP3 needs:
- read a full message
- read N lines or the full header
- get the list of message keys and their sizes
- get a count of the total number of messages (and possibly their total
size)
- delete a message
Our repository currenlty is not so good for the "key size" list and for
the "total size" result.
... and that requires operations that could be quite expensive.
Is there a similar "analysis" done for Imap? I know that the imap
protocol itself provides a lot of features, but I also wonder if the
imap clients uses all of IMAP commands in all the ways or if we have a
subset of used "commands with specific parameters".
Well, imap makes no sense without flags and uids. Well, maybe the internalDate
could be faked to the date in the header...
For example: it's a common practice to access news through imap by
#news.comp.os.linux etc.
It's even imaginable to access #spool.* through IMAP for administration.
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. :-)
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
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
