On Oct 22, 2008, at 3:29 AM, Markus Wiederkehr wrote:

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.

I don't pretend to understand any details of what you are proposing but IMO it is not too hard to write container-agnostic IOC components (at least for non-intrusive containers). Then you can write a little bit of code to wire stuff together when running outside an IOC container, and, if necessary, adapters for use in intrusive IOC containers.

Don't know if this is relevant here...
thanks
david jencks



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]



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to