james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bernd Fondermann" <bernd.fonderm...@googlemail.com>
Subject Re: MIME4J - remove parent reference from Body?
Date Thu, 02 Oct 2008 17:36:52 GMT
On Wed, Oct 1, 2008 at 15:39, Markus Wiederkehr
<markus.wiederkehr@gmail.com> wrote:
> On Wed, Oct 1, 2008 at 2:21 PM, Stefano Bagnara <apache@bago.org> wrote:
>> Markus Wiederkehr ha scritto:
>> > 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.
>> The idea is interesting, but I'm not sure how we can deal with details.
>> Do you want to place each of that objects (Body,Field,Header,Message)
>> behind a Copy-On-Write proxy object? Or do you want to do this for
>> TempFiles ? Or something I misunderstood?
> I don't think any proxy objects are necessary. Let me explain.
> Let's start with Header. Header maintains a list of header fields (instances
> of class Field). From what I see Field and its subclasses seem to be
> designed to be immutable. This is a good thing because it means you don't
> have to copy the actual fields if you copy the header. So cloning a Header
> object would be quite easy. Field would have to remain immutable in future
> releases though.
> Now consider Entity (Message and BodyPart). An Entity has a Header, a Body
> and a parent Entity. A copy of an Entity should have a copy of the original
> Header and a copy of the original Body. But it should be detached from the
> original parent (resulting in the copy's parent to be null).
> So Body needs to be Cloneable too. Multipart, Message, TempFileBinaryBody
> and TempFileTextBody are Body implementations. Message has already been
> taken care of because it is also an Entity.
> To copy a Multipart you basically have to copy the list of BodyParts it
> holds. BodyParts are already Cloneable so we can clone each element of the
> list. Each cloned BodyPart can than be attached to its new parent (the
> Multipart's parent in this case).
> Now have a look at TempFileBinaryBody. It maintains a reference to a
> TempFile object. TempFile itself is not immutable but since
> TempFileBinaryBody is read-only the temp file does not have to be copied
> when cloning a TempFileBinaryBody. Both the original and the copy can simply
> reference the same TempFile.
> Now the only problem is that a TempFile cannot be deleted once a
> TempFileBinaryBody is disposed if there are still other TempFileBinaryBody
> using it. This can easily be solved with a reference counter in
> TempFileBinaryBody.
> So to summarize a Message (or any part of it) could be cloned without having
> to copy the header fields or the TempFiles on disk. So the copy would not
> occupy much memory but would still be completely independent from the
> original.
> Markus

I share the goal of having mutations of a mail without duplicating all
related parts and underlying resources. But this has to be done
Incorporating this into the core container classes representing the
message is not the way to go, I think.
Managing (cloning, copying, cleaning up) a tree of message components
are concerns that should be handled by a separate utility layer
specialized classes.
Also, the underlying storage mechanism (tempory files currently)
should be moved out so it becomes exchangable.

Hope this does not discourage you, because this is very important
stuff which is in on/off discussion for a long time.


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

View raw message