IMHO, after we'll have done this refactorings we will be able to introduce
optimized versions of spoolmanager and repositories and to not move
mimemessages around anymore. I think we should try and see wether it works
or not: we can fix names, do more refactoring, apply new optimization once
this work.
1) Join SpoolRepository and MailRepository interfaces: every MailRepository
can become a SpoolRepository by adding a simple wrapper.
This change would be backward compatible because it's mostly an internal
issues (only people that implemented repositories would care).
1a. I think we can do everything using only SpoolRepositories: to provide a
SpoolRepository is not more difficult than to provide a MailRepository.
1b. I would like later rename the current SpoolRepository to MailRepository
(after the removal of the current MailRepository) because the name is more
appropriate.
1c. Later I would like to add more flexible "accept" command with a sort of
query language to accept specific messages (this is the *only way* to
achieve optimizability in remotedelivery outgoing spooler management)
2) Create a new MessageRepository interface (similar to the avalon
StreamRepository): it only handles Stream storage by key (the MimeMessages
stream representation) (we don't need Mail/MailImpl for POP3/IMAP). It
provides the list of messages (message_name, message_size),
store(message_name, stream), remove(message_name),
2a. Create a JDBC implementation with repository_name, message_name,
message_size, message_body (this can use most of the current
JDBCMailRepository by removing unused envelope informations: by doing this
we can easily switch to MessageRepository without changing the current db
structure). If message_size does not exists or message_size is 0 we
calculate the size by loading the message (backward compatibility)
2b. Do we need locking on MessageRepositories? IMHO NO, we don't. Who does
care if multiple items do retrieve a stream and try to delete it multiple
times?
3) Create a new JDBCRepository.java (copied from the current
JDBCSpoolRepository):
3a. Add new sqlResources queries to retrieve messages and mail_attributes in
a single operation.
3b. The new JDBCRepository will be faster that the old "compatible" one.
3c. JDBCRepository will need a MessageRepository to store the message
sources (like the current dbfile)
4) Split the ToRepository in ToMessageRepository and ToMailRepository:
4a. ToMessageRepository will store only the MimeMessage stream (looses
envelope informations)
4b. ToMailRepository will need a MailRepository as an argument (the one
currently named SpoolRepository)
4c. Define the "ToRepository" end: remove it? Behave as ToMailRepository?
5) FromRepository to FromMessageRepository / FromMailRepository:
5a. FromMailRepository will work as the current FromRepository.
5b. FromMessageRepository will probably act like fetchmail (rebuild envelope
informations from mimemessage content) (we need to pay attention to
concurrency as the MessageRepositories does not lock, maybe we should add a
convenience retrieveAndDelete to the MessageRepository interface).
6) Message Names: IMHO we should change the
"MailSender/MailetContext.send(...)" and the "Repository.store(...)" methods
so to have the Name as return value. This way you get the Name when you send
the message (no more needs for newName/getId).
6a. In order to have cleaner flow we should le the container to move
messages when we use the "store" on a new repository. Retrieving a message
from a repository and storing it to a new repository should automatically
invoke the remove from the previous repository (we probably could handle
this by bringing a reference to the owner repository in MailImpls retrieved
by repositories): in fact this should happens everytime we try to store a
message that already has a MessageID (this change what we can do: for
example in RemoteDelivery we now to multiple store for the same message
after we change it's properties, we can't do this anymore).
7) IMAP: create a FolderTreeMessageRepository that extends
MessageRepository.
7a. FolderTreeMessageRepository will contain methods to browse subfolder and
obtain FolderTreeMessageRepositories for each subfolder.
7b. Do we need more than this to provide Imap persistence? (Flags? Date?
long Uid? Message attributes?)
in ImapMessageAttributes I see: getInternalDate,
getInternalDateAsString, getSize, getEnvelope, getBodyStructure. Do we need
to provide them in the MessageRepository interface? Are query over this
attributes needed? Are this attributes sent to the client without the body?
If so, should we add this informations to a JDBCMessageRepository
implementation (caching the data in specific fields) ? Are there
performance/size problems by using the folder path as a repository_name ?
Does IMAP use this to point folders? How long can be the path? Do you ever
need to access multiple folders in the same query by using IMAP?
If you want to use IMAP and POP3 you will have to use a
FolderTreeMessageRepository (maybe ImapMessageRepository) implementation. If
you just need POP3 you can even use a simple MboxMessageRepository.
IMHO the ONLY way to move is to CODE something (I've seen too much
discussions/proposals and too few code in the last year). Noel's sentence "
the key to moving data quickly was not to move it" is probably from more
than 2 years ago...
I guess in the same time I wrote this mails I would have implemented the 7
steps above: you could now better understand what I meant and better discuss
new changes or reverts.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
