Markus Wiederkehr [mailto:[EMAIL PROTECTED] wrote on: 22 October 2008 11:30
> Hi Steve,
>
> thank you very much for your response.
>
> On Wed, Oct 22, 2008 at 12:15 AM, Steve Brewin
> <[EMAIL PROTECTED]> wrote:
> > > 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...
>
> I think Mime4j should be independent from James Server.
Absolutely, this is an misunderstanding. Mime4j should have as few dependencies
as possible.
I'm suggesting that there is no need for a new bespoke mechanism for
configuring alternate providers. There is tried and tested pattern which does
the job and offers great flexibility in how the job gets done - IOC. Once an
IOC pattern is adopted, either simple default builders can be used to assemble
things or they can be replaced by an IOC container such as Pico or Spring.
Following this pattern opens up more options without closing any.
> I want to use
> Mime4j to parse or create messages in applications that are unrelated
> to James. So whatever IOC container James uses (Phoenix components or
> do you mean something else?) is not available in Mime4j.
>
> I also think that Mime4j should not inflict a certain IOC container on
> the user. I want to decide what IOC container to use in my
> application, if any.
>
> But maybe I misunderstand and you mean something
> different/simpler entirely.
I don't think MessageBuilder shoud be hard wired to use TempStoreProvider.
Using an IOC pattern MessageBuilder would have a provider injected into it.
This provider would be defined by an interface, lets call this
ITempStoreProvider. Using CDI, the MessageBuilder ctor would be:
public MessageBuilder(ITempStoreProvider anITempStoreProvider)
{
_iTempStoreProvider = anITempStorePovider;
}
The current TempStoreProvider class would implement ITempStoreProvider. Now
MessageBuider is not coupled to TempStoreProvider, but may still use it as
before.
> If we agree that one storage strategy per application is sufficient
> then the TempStoreProvider could be as simple as:
>
> abstract class TempStoreProvider {
> // static initializer that reads system property to provide a
> default instance..
>
> public static TempStoreProvider getInstance() { ... }
> public static void setInstance(TempStoreProvider provider) { ... }
>
> public abstract TempStore createTempStore(InputStream in);
> }
>
> interface TempStore {
> InputStream getContent();
> void delete();
> }
>
> One thing that might be interesting with this design is that it allows
> for one TempStoreProvider to decorate or wrap another one. Let's say
> you have one implementation that stores the content in temporary files
> and another that does something more sophisiticated like writing to
> disk only if a certain size is exceeded. Now you could write a wrapper
> that encrypts/decrypts the content. This wrapper can then be used with
> both back-ends.
>
> > > 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.
>
> I believe if there should only be one storage strategy per application
> then dependency injection is not really necessary and if it should be
> possible to use different strategies with different messages automatic
> dependency injection does not help.
>
> > > 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.
>
> There are certain things I would like to be able to do with Mime4j.
> For example I would like to detach a message body from one message and
> attach it to another. I would also like to have Body implementations
> that can be shared between messages. It should be possible to create a
> structural copy of a message without actually copying the contents of
> text or binary message bodies. This could be accomplished by a simple
> reference counting mechanism.
>
> Or maybe I would like to remove or replace a certain part of a
> multipart/mixed message. Then this removed or replaced BodyPart would
> have to be disposed of while the message it belonged to still lives
> on.
>
> If you have a MessageSession associated with Message how could a
> BodyPart live independently of a message for example? If I want to
> create a message from scratch instead of parsing it from an input
> stream this can sometimes be necessary. Imagine a helper method that
> creates a BodyPart that may (or may not) be added to a Multipart
> later.
>
> I'm not saying some MessageSession object is a bad idea but I don't
> understand how it could work exactly ATM.
I'm not saying some MessageSession object is a good idea either, just a
recognisable pattern.
A MessageSession object would deal with the lifetime of a Message. How it is
morphed by the use cases you propose is more complex.
It's late, so I'll chew on this and reply tomorow(ish).
> Bye,
> Markus
Cheers
--Steve
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
