james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Bagnara <apa...@bago.org>
Subject Re: Questions on the Mail and MailRepository interfaces
Date Tue, 15 May 2007 10:40:33 GMT
Jukka Zitting ha scritto:
> OK. I guess the attributes can be any serializable objects, so the
> implementation should use standard Java serialization in case it
> doesn't know the type of the attribute.

Yes, Java serialization is the way to go.
"public Serializable setAttribute(String key, Serializable object)"

> Is the repository implementation required to keep the original key
> (from mail.getName()) when stroring a new message, or can it replace
> it with an internal identifier?

It is not documented, so to be safe you should keep the name.

On the other hand I'm almost sure (99%) our current codebase never keeps
"references" to the name.

The main problem with "repository generated keys" is that the current
interface does not give you a way to know what key has been assigned to
a stored message.

Just make sure that if I call store for a mail with an existing key you
update the same mail and do not create a new one.

>> Maybe some of this things should be changed, I simply replied with what
>> the current code does and expects.
> ACK. Thanks a lot for the help!

You probably noticed that we currenlty have SpoolRepository and
MailReposutory and that SpoolRepository is a MailRepository with some
added method (every MailRepository could expose SpoolRepository services
via a simple wrapper).

We discussed many times about changing this so to have a
MessageRepository that should be similar to the current MailRepository
but only include mail.message (MimeMessage) informationd and an
EnvelopeRepository (to replace SpoolRepository) that should only store
the envelope (everything else you find in the Mail object but the
MimeMessage) and reference a Message from a MessageRepository. (Maybe
JCR better fits the MessageRepository and JMS better fits the
EnvelopeRepository for their respective persistence natures)

We never did that because this would break backward compatibility and
current trunk is still storage+config.xml compatible with 2.3.0/2.3.1

Imho backward compatibility is not a big issue: we should just take care
to tag the last trunk version before "breaking" it.

Thank you too,

some related link, if you are interested:

To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

View raw message