Re: MIME4J - remove parent reference from Body?

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

Okay, I am overwhelmed by your many responses ;-)

In the meantime I have given it some thought and I think removing the parent
reference from Body is not such a good idea after all because with this
approach disposing a Message that shares body parts with another message
would destroy the other message.

So I propose something different. How about making Field, Header, Message
and Body cloneable?

What I have in mind is copying the structure of an e-mail without copying
the backing TempFiles. So for example two TempFileBinaryBodys could refer to
the same TempFile while maintaining a reference counter. The TempFile should
get deleted if both TempFileBinaryBodys are disposed.

This way one could clone an entire message and manipulate it or just clone a
BodyPart and attach it to another message.

I would like to implement this if you are interested in such a feature.

Thanks,
Markus

PS: and could someone please take a look at MIME4J-72, 80 and 81?


On Mon, Sep 29, 2008 at 6:10 PM, Markus Wiederkehr <
markus.wiederkehr@gmail.com> wrote:

> Before I file another MIME4J issue I would like to ask your opinion.
>
> At the moment we use Sun's JavaMail API to process and manipulate e-mails.
> I would like to go away from JavaMail so I am currently evaluating MIME4J to
> see if is an alternative. So far it looks very promising.
>
> Our use case is typically the following: parse an incoming message; run the
> message through a workflow that manipulates it (can be: apply a signature,
> add/remove/replace an attachment, etc.); re-send and/or archive the message.
>
> Now the problem is that I would basically like to create a new Message
> object that should contain some parts from the original message and some new
> parts. The original message should not modified though. In other words I
> would like to create a Message that shares some Part objects with another
> Message.
>
> Currently this is not possible because Part holds a reference to a parent
> Entity (getParent() and setParent()) and a Part can of course have only one
> parent.
>
> So the question is do you think it would be possible to remove this parent
> reference?
>
> In the current release the parent entity is used for two purposes:
> 1) determine the message boundary and charset in Multipart.writeTo()
> 2) in Entity.getMimeType() to ask the parent if the entity does not have a
> Content-Type header field.
>
> Number one could be resolved by adding an "Entity parent" parameter to
> Body.writeTo(). But I am not sure about number two. Would it suffice to
> return null instead of delegating to a parent entity?
>
> I have attached a patch for #1 to illustrate what I mean. Hope it gets
> through the mailing list..
>
> Markus
>

Re: MIME4J - remove parent reference from Body?

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

On Thu, Oct 2, 2008 at 10:34 PM, Robert Burrell Donkin <
robertburrelldonkin@gmail.com> wrote:

> On Thu, Oct 2, 2008 at 11:54 AM, Markus Wiederkehr
> <ma...@gmail.com> wrote:
> > On Wed, Oct 1, 2008 at 12:32 PM, Markus Wiederkehr <
> > markus.wiederkehr@gmail.com> wrote:
> >
> >> What I have in mind is copying the structure of an e-mail without
> copying
> >> the backing TempFiles. So for example two TempFileBinaryBodys could
> refer to
> >> the same TempFile while maintaining a reference counter. The TempFile
> should
> >> get deleted if both TempFileBinaryBodys are disposed.
> >>
> >
> > I am 90 percent done with implementing this feature. I would really
> > appreciate it if this feature could make it into 0.5. Do you think this
> is
> > still possible?
>
> it's more important to get this design right than to squeeze it into
> 0.5. IMHO we should look to release 0.5 ASAP, if necessary a branch
> can be taken.
>
> i see no release why we shouldn't just cut a prompt 0.6 once message
> has been sorted out.


Okay, I have no problem with that. I can even live with an SVN snapshot for
a while. But I would really like to see this feature included in one form or
another.

Markus

Re: MIME4J - remove parent reference from Body?

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

On Thu, Oct 2, 2008 at 11:54 AM, Markus Wiederkehr
<ma...@gmail.com> wrote:
> On Wed, Oct 1, 2008 at 12:32 PM, Markus Wiederkehr <
> markus.wiederkehr@gmail.com> wrote:
>
>> What I have in mind is copying the structure of an e-mail without copying
>> the backing TempFiles. So for example two TempFileBinaryBodys could refer to
>> the same TempFile while maintaining a reference counter. The TempFile should
>> get deleted if both TempFileBinaryBodys are disposed.
>>
>
> I am 90 percent done with implementing this feature. I would really
> appreciate it if this feature could make it into 0.5. Do you think this is
> still possible?

it's more important to get this design right than to squeeze it into
0.5. IMHO we should look to release 0.5 ASAP, if necessary a branch
can be taken.

i see no release why we shouldn't just cut a prompt 0.6 once message
has been sorted out.

- robert

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

Re: MIME4J - remove parent reference from Body?

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

On Wed, Oct 1, 2008 at 12:32 PM, Markus Wiederkehr <
markus.wiederkehr@gmail.com> wrote:

> What I have in mind is copying the structure of an e-mail without copying
> the backing TempFiles. So for example two TempFileBinaryBodys could refer to
> the same TempFile while maintaining a reference counter. The TempFile should
> get deleted if both TempFileBinaryBodys are disposed.
>

I am 90 percent done with implementing this feature. I would really
appreciate it if this feature could make it into 0.5. Do you think this is
still possible?

If yes, could someone please commit my latest patch for MIME4J-72 (with or
without finalizers) so I can base my new patch on that one.

Then I would file a new issue on JIRA and attach the new patch for cloning
messages.

Thank you,
Markus