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 < [EMAIL PROTECTED]> 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 >
