Markus Wiederkehr [mailto:[EMAIL PROTECTED] wrote on: 18 October 2008 11:59
Hi Markus Here are a few comments which are purely my take on the architectural choices that might be made. Both yourself and Bernd have raised very insightful issues. > 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. +1 > 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. I think that just an application level strategy is reasonable at this time. To do more adds levels of complexity without clear use cases to justify it. > 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. Perhaps I'm misunderstanding, but I don't see the the need for a TempStoreProvider class to assemble things. I'd like to see a simple interface and the ability to inject an implementation of the interface. A container would do the injection, IOC style, just as is done elsewhere in James... > 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. ...then MessageBuilder is not coupled to how the TempStore implementation is obtained. > 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. It sounds like you have a "session" like pattern here. So, you could define a "MessageSession" object, an instance of which would be created at Message creation time, to which all artefacts related to the processing of the Message are attached, including the TempStore. The MessageSession, and therefore all attached objects, would be destroyed when the Message is disposed off. This might be overkill if the TempStore is the only object ever likely to be associated with the lifetime of the Message, but I suspect it won't be. > I could post some code as a basis for discussion if you want. > > Markus I hope this helps. Cheers -- Steve --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
