Norman Maurer wrote:
Just one quick question for add this features..
you said:
that multiple calls to store(Mail) using the same mail will create a new
object in the store the first time and update the same object the
following calls.
So if store(Mail) is called again with the same email (what you mean
with same ? identical?) it should override the "old" email ? Or what for
updates you talk about?
Storing a message with the same name (key) in a store where the same
name already exists overwrites it.
So store() call is an "insertOrUpdate" function, based on the unique key
of the object (mail.getName()) for that store.
We should change the whole repository interface because this is a big
limitation of the current interfaces but we can't do this for 2.3.0. So
we should either find workarounds or wait to have a 2.3.0 final and
start working on the 3.0.
BTW, I'm happy you're working on this because we can better understand
the current interfaces and what we need to change for 3.0 in order to
have better support of javamail stores as "message" stores.
The problem with random keys is fixed here now by generate a md5 for
each message and use this as Key. So the key is on every call the same
for each message.
I try to describe a problematic scenario with metacode:
// when we create mails WE assign our own names
// the repository has no power on it.
Mail a = new Mail(name => "key1");
// this store the message in the repository
repos.store(a);
// this MUST find that message
Mail b = repos.retrieve("key1");
b.getMessage().setSubject("new subject");
// this updates the same message in the store.
repos.store(b);
To do that you should probably store the message, keep in memory its MD5
and its userkey ("key1"). When I retrieve a message you should lookup
both MD5s and userKeys. When I store a message you should check wether
the userKey already exists and update the MD5 according to message changes.
This is not easy: if you don't want to rehash the whole repository at
each operation you probably should create an md5->messagenumber cache
and hope the message numbers are not too volatile. Then you start trying
with the cached messagenumber, retrieve it, verify the md5 is the one
you expected, if so you can continue otherwise you have to rehash the
whole repository and clean caches.
Not sure if this feature worth the work right now (it won't be fast
anyway, and it won't support multiple identical messages in the same store)
As a sidenote, I already wrote about repository refactoring I think we
should evaluate:
1) SpoolRepository and MailRepository should be merged in a single
interface (it's easy enough to provide spoolrepository services over a
mailrepository, so we don't need both of them). I would call the unified
object MailRepository. We should look at the JMS interfaces for queue to
improve our interface (e.g: the unique key should be generated by the
repository and not by us)
2) MessageRepository: this does not persist Mail objects but only
Messages (MimeMessages). It probably is really similar to javamail
stores and we should provide a JavamailStoreMessageRepository.
MessageRepositories should support a rich interface to simplify IMAP
usages (search, folders, etc..).
3) MailRepositories could use MessageRepositories for their message
persistence needs.
4) MessageRepositories should be able to move messages directly between
multiple repositories (would help us to improve performance a lot when
using uniform repositories)
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
