james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Markus Wiederkehr" <markus.wiederk...@gmail.com>
Subject [mime4j] improve support for creating and manipulating messages
Date Sat, 22 Nov 2008 21:01:58 GMT
First of all I want to thank Oleg for committing MIME4J-83 and 85.

Now that the source is based on Java 5 and StorageProvider is in I
would like to propose (and contribute) a few more things:

1) I think Mime4j's support for creating messages programatically
could be improved. Currently it is not even possible to create a
simple text/plain message out of the box. This is because the user has
to write a custom class that holds the message body first.
TempFileBinaryBody and TempFileTextBody are package private and there
is no other alternative.

But instead of simply making these classes public I propose the
addition of a factory class. This factory should provide methods for
creating text and binary bodies from various sources (InputStreams and
Strings for now).

2) I believe it would be cool if a message Body could be shared
between Entities. This would open the door for creating a structural
copy of a message without actually copying the contents of text and
binary bodies. Mime4j could become a more versatile API for
manipulating messages. For example it could be possible to copy parts
of an existing message and attach them to another message.

This should be easy to accomplish by adding a reference counting
mechanism at the right place (either Storage or Body).

3) A Message is a composite data structure. This composite should be
accompanied by a visitor to allow for decoupling of algorithms that
work on the composite from the composite itself.

This has already proven to be a controversial topic but maybe we can
come to a solution on second attempt.

4) Visitor implementations for copying or manipulating messages.

I even like the idea of replacing (or accompanying) the Body.writeTo()
method with a visitor implementation. One advantage would be that the
code would no longer be scattered around various message classes.
Instead it would all be in one class, the visitor. Another advantage
would be that instead of three different Mode constants one could
simply use different visitors for different header encoding

So I would like to open new JIRA issues for these four points, if that
is okay with you. But please don't let me wait three to four weeks
before you even consider one of my patches. A faster pace would be
very much appreciated.



To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

View raw message