On Sat, Nov 22, 2008 at 9:01 PM, Markus Wiederkehr <[EMAIL PROTECTED]> wrote: > First of all I want to thank Oleg for committing MIME4J-83 and 85.
+1 and thanks to you for contributing it > Now that the source is based on Java 5 and StorageProvider is in I > would like to propose (and contribute) a few more things: > > 1) I think Mime4j's support for creating messages programatically > could be improved. Currently it is not even possible to create a > simple text/plain message out of the box. This is because the user has > to write a custom class that holds the message body first. > TempFileBinaryBody and TempFileTextBody are package private and there > is no other alternative. > > But instead of simply making these classes public I propose the > addition of a factory class. This factory should provide methods for > creating text and binary bodies from various sources (InputStreams and > Strings for now). sounds reasonable > 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? > This should be easy to accomplish by adding a reference counting > mechanism at the right place (either Storage or Body). easy to accumplish but probably tricky to maintain (just a comment, not a criticism) > 3) A Message is a composite data structure. This composite should be > accompanied by a visitor to allow for decoupling of algorithms that > work on the composite from the composite itself. > > This has already proven to be a controversial topic but maybe we can > come to a solution on second attempt. visitors are a good idea but this is probably best discussed in a separate thread > 4) Visitor implementations for copying or manipulating messages. > > I even like the idea of replacing (or accompanying) the Body.writeTo() > method with a visitor implementation. One advantage would be that the > code would no longer be scattered around various message classes. > Instead it would all be in one class, the visitor. Another advantage > would be that instead of three different Mode constants one could > simply use different visitors for different header encoding > strategies. at first glance, this sounds like a good approach > So I would like to open new JIRA issues for these four points, if that > is okay with you. sounds great > But please don't let me wait three to four weeks > before you even consider one of my patches. A faster pace would be > very much appreciated. everyone's really busy right now :-/ but please don't let that stop you submitting the patches - robert --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
