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]