Hi, On Thu, Oct 9, 2008 at 11:26 PM, Bernd Fondermann <[EMAIL PROTECTED]>wrote:
> [..] The current mime4j implementation uses "temporary storage", making use of > temporary files as supported by the JDK. I have to admit I did not look thoroughly enough. While the general contract of o.a.j.mime4j.message.storage.TempFile seems to be abstract enough (barely) to allow for various storage strategies to be implemented the contract of TempPath clearly is not. I'm sorry I suggested otherwise before. I think we need a more generic storage mechanism for message bodies. The storage strategy could be anything from entirely in memory to entirely on disk. Even keeping the message bodies in encrypted files could be a possible strategy if security is an issue. The storage strategy should be exchangeable. This leads to the question if it needs to be exchangeable on an application level alone (one global strategy) or if there are applications that need different strategies for different messages. Personally I would be content with the former but I think we should not ignore the latter. What would you think about a generic interface TempStore that does not make any assumptions on how or where the data is stored and an abstract class TempStoreProvider that can be used to create TempStore instances? TempStoreProvider should also have static methods to add and remove provider instances. In addition there should also be a default provider that is exchangeable on the application level. The class MessageBuilder could then decide which TempStoreProvider instance it wants to use. Maybe by adding a second constructor with a provider identifier as parameter. It should also be possible to simply use the default provider. One question that still remains is the lifetime of the TempStore instances. I still think it should be coupled to the lifetime of the Message object they belong to. And since finalizers can't be relied on the dispose method introduced in 0.5 can be used to explicitely destroy a message and free the backing TempStore instances. I could post some code as a basis for discussion if you want. Markus
