On Fri, Nov 28, 2008 at 6:19 PM, Markus Wiederkehr
<[EMAIL PROTECTED]> wrote:
> On Thu, Nov 27, 2008 at 11:40 PM, Robert Burrell Donkin
> <[EMAIL PROTECTED]> wrote:
>> On Sat, Nov 22, 2008 at 9:01 PM, Markus Wiederkehr
>> <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to