[mime4j] improve support for creating and manipulating messages

[Markus Wiederkehr <ma...@gmail.com>]

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
strategies.

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.

Thanks,

Markus

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

Re: [mime4j] improve support for creating and manipulating messages

[Markus Wiederkehr <ma...@gmail.com>]

On Sun, Nov 30, 2008 at 9:20 PM, Robert Burrell Donkin
<ro...@gmail.com> wrote:
> On Fri, Nov 28, 2008 at 6:19 PM, Markus Wiederkehr
> <ma...@gmail.com> wrote:
>> Unfortunately I see no way to eliminate the parent reference in
>> Entity.getMimeType().
>>
>> Maybe someone has an idea?
>
> that depends on whether it's necessary to support dynamic alteration
> of the parent's type to and from multipart/digest (otherwise
> isPartOfDigest could just be injected)

I'm not sure I understand what you mean by altering the parent's type.
Changing the type from multipart/digest to some other multipart type
would require to explicitly set the content type message/rfc822 on all
BodyParts. Otherwise the BodyParts' content type would miraculously
change..

As for injecting a boolean.. how would the client know the correct
value if there is no parent to ask?

With my patch for MIME4J-88 I chose to keep the parent reference - for
now. It would be easy to amend the contract of SingleBody#copy to
allow for "return this" if the parent reference ever gets removed.

Markus

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

Re: [mime4j] improve support for creating and manipulating messages

[Robert Burrell Donkin <ro...@gmail.com>]

On Fri, Nov 28, 2008 at 6:19 PM, Markus Wiederkehr
<ma...@gmail.com> wrote:
> On Thu, Nov 27, 2008 at 11:40 PM, Robert Burrell Donkin
> <ro...@gmail.com> wrote:
>> On Sat, Nov 22, 2008 at 9:01 PM, Markus Wiederkehr
>> <ma...@gmail.com> wrote:
>>> 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.
>>
>> cool, yes
>>
>> i suspect that there may be some wrinkles and either the API may need
>> revision, or the sharing needs to happen at a lower level. (this is a
>> comment, not a criticism - i'm happy to see the API improved)
>>
>> for example, ATM body has a parent property. how would you cope with that?
>
> I was thinking about creating a new Body that shares the Storage
> object with the original. The new body can have a different parent.
> The Storage object can easily be reference counted by writing a
> wrapper class (Storage is an interface).

ok

> But your reply made me investigate whether the parent reference could
> be removed entirely. As it is the parent is needed in two places.
> First in Multipart.writeTo() to determine the boundary string. And
> second in Entity.getMimeType() if the content type header field is not
> present (because the default value is message/rfc822 if the parent is
> multipart/digest, text/plain otherwise)..
>
> The first usage in Multipart.writeTo() is no problem if a visitor
> writes the message. The visitor can easily remember the parent entity.
>
> Unfortunately I see no way to eliminate the parent reference in
> Entity.getMimeType().
>
> Maybe someone has an idea?

that depends on whether it's necessary to support dynamic alteration
of the parent's type to and from multipart/digest (otherwise
isPartOfDigest could just be injected)

- robert

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

Re: [mime4j] improve support for creating and manipulating messages

[Markus Wiederkehr <ma...@gmail.com>]

On Thu, Nov 27, 2008 at 11:40 PM, Robert Burrell Donkin
<ro...@gmail.com> wrote:
> On Sat, Nov 22, 2008 at 9:01 PM, Markus Wiederkehr
> <ma...@gmail.com> wrote:
>> 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.
>
> cool, yes
>
> i suspect that there may be some wrinkles and either the API may need
> revision, or the sharing needs to happen at a lower level. (this is a
> comment, not a criticism - i'm happy to see the API improved)
>
> for example, ATM body has a parent property. how would you cope with that?

I was thinking about creating a new Body that shares the Storage
object with the original. The new body can have a different parent.
The Storage object can easily be reference counted by writing a
wrapper class (Storage is an interface).

But your reply made me investigate whether the parent reference could
be removed entirely. As it is the parent is needed in two places.
First in Multipart.writeTo() to determine the boundary string. And
second in Entity.getMimeType() if the content type header field is not
present (because the default value is message/rfc822 if the parent is
multipart/digest, text/plain otherwise)..

The first usage in Multipart.writeTo() is no problem if a visitor
writes the message. The visitor can easily remember the parent entity.

Unfortunately I see no way to eliminate the parent reference in
Entity.getMimeType().

Maybe someone has an idea?

Markus

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

Re: [mime4j] improve support for creating and manipulating messages

[Robert Burrell Donkin <ro...@gmail.com>]

On Sat, Nov 22, 2008 at 9:01 PM, Markus Wiederkehr
<ma...@gmail.com> wrote:
> First of all I want to thank Oleg for committing MIME4J-83 and 85.

+1

and thanks to you for contributing it

> 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).

sounds reasonable

> 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.

cool, yes

i suspect that there may be some wrinkles and either the API may need
revision, or the sharing needs to happen at a lower level. (this is a
comment, not a criticism - i'm happy to see the API improved)

for example, ATM body has a parent property. how would you cope with that?

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

easy to accumplish but probably tricky to maintain (just a comment,
not a criticism)

> 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.

visitors are a good idea but this is probably best discussed in a
separate thread

> 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
> strategies.

at first glance, this sounds like a good approach

> So I would like to open new JIRA issues for these four points, if that
> is okay with you.

sounds great

> 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.

everyone's really busy right now :-/ but please don't let that stop
you submitting the patches

- robert

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