Hi Stefano,
Stefano Bagnara schrieb:
Here are the goals:
1) Release james 2.4 as storage-compatible with older james 2.x.
2) Start including some IMAP stuff in trunk.
As a sidenote I think that we can safely include your
javamailstore-mailrepository work in trunk, but this has not much to do
with IMAP.
Yes I think so. While working on MessageRepository performance and compatibility
of javamailstore-mailrepository could get better by lowering the requirements.
(no user generated key).
I started reviewing what you publshed here:
http://www.joachim-draeger.de/JamesImap/drafts.html
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.
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 thought that the following steps could be included in the roadmap as a
starting point.
1) the MessageRepository (Mailbox) interface: this would replace the
current MailRepository but would not include the Mail object but simply
the Message object/stream (and eventually some more attributes). The
default messageRepository generates its own key and provides few methods
to store/retrieve/delete messages (maybe we could add "move" later).
Imho the basing MessageRepository should be really, really easy!
Well, but you can't avoid the uid-stuff in any way.
And you need something to manage hierarchy.
But I think it would be really a good step to introduce a MessageRepository now,
to be able to deprecate MailRepository for user mailboxes in the future.
MessageRepository should be treated through a session. For many storage backends
you need to do some caching or keep resources open.
Because the GC is not an option the MessageRepository should be told, when it is
no longer needed, so it can free resources.
Even for pop3 a permanent key is needed, which could be hash-sum. But that key
should only be provided on demand. Who needs it when storing a message in a smtp
-session?
2) some sort of named repository mapper: this has been discussed in past
and is described here:
http://wiki.apache.org/james/JamesV3/Plans (Message repository directory
structure).
But it would be still needed to introduce a Manager class to
create/rename/delete and access those repositories.
The advantage of logical mailbox names is, that the mapping possibilities can be
extended in the future.
At first every user mailbox like #users.joachim.INBOX ( I prefer the common IMAP
notation) is mapped to one sort of repository.
In the future there may be even user attributes from the User object, that
define where this mailbox exists.
The accessing services like smtp/pop/imap/nntp servers or mailets don't have to
care about it. They only have to care if the capabilities are sufficient for the
purpose.
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.
Once this will be in the repository we will discuss what is the minimal
set of features you included in ImapMailboxRepository to be able to
include the imap code in trunk so that I can send a message via SMTP and
retrieve via IMAP. I think that the goal is to be able to commit the
imap code to trunk. As soon as the code will be on trunk it will be
easier to discuss following steps and to involve further people.
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.
Well I think that moving from MailRepository to MessageRepository is a good
thing, but I don't believe that it could evolve to a repository with imap
capabilities.
It's a good chance to do a rewrite and e.g. use transactions instead of local
locking.
At the moment I do some experiments on detecting external deliveries/changes to
the database and keeping message numbers stable through a session.
But maybe I will put out a prototype without that advanced stuff first.
For integration with James it will provide a MailRepository/MessageRepository
wrapper, that could be simply configured in config.xml.
For the impatient: (non executable, work in progress code)
http://svn.joachim-draeger.de/repos/james/mailboxmanager/trunk/src/java/org/apache/james/mailboxmanager/torque
Acl, User/Groups, triggers and quotas are a lot of stuff, and imo we
can't put everything in a single step.
I agree and that corresponds to my roadmap draft.
Joachim
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
