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. 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.
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.
Bye,
Markus
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
