On Wed, Oct 1, 2008 at 2:21 PM, Stefano Bagnara <[EMAIL PROTECTED]> 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
