[jira] Commented: (MAILET-17) Add support for other mail parsing APIs such as mime4j

["Robert Burrell Donkin (JIRA)" <ma...@james.apache.org>]

    [ https://issues.apache.org/jira/browse/MAILET-17?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12630744#action_12630744 ] 

Robert Burrell Donkin commented on MAILET-17:
---------------------------------------------

I'm very interested in moving away from javax.mail altogether for the next generation Mailet API. I'm a little hazy about the best design but I think I understand some of the my requirements now.

* I see no reason why mail should just mean RFC822: I want to take Atom feeds, XMPP and more then feed them into the same pipe. coupling to javax.mail prevent this. I would like to see the next generation Mailet API focus on MIME messages with rich meta-data.

* Protocols should stream straight to spool. It should be possible in the vast majority of cases to understand whether a mail is interested enough not to be rejected immediately by examining a small number of initial buffers. Rather than assembling a complete message for storage, once a decision has been taken to store the message the content should be streamed directly to buffer.

* The Mailet API should not insist on a DOM. DOMs are inefficient and hard to optimise. Most mailets don't edit content. Those that do should be able to do so on a composite document basis. In a multipart MIME document, the mailet should be able to edit or replace just part 4 of the message. 

* The Mailet API should provide modification methods for meta-data copying and forking that do require mutliple copying of the underlying bits. 



> Add support for other mail parsing APIs such as mime4j
> ------------------------------------------------------
>
>                 Key: MAILET-17
>                 URL: https://issues.apache.org/jira/browse/MAILET-17
>             Project: Mailet
>          Issue Type: Improvement
>          Components: Core API
>            Reporter: Markus Wiederkehr
>
> Currently the interface Mail is described as a wrapper around a MimeMessage with routing information. For various reasons it would be nice if the user could decide what mail API to use.
> This could be accomplished by simply adding a method to retrieve the raw input stream of the message. The user can then use a mime4j parser or whatever API is best fitting to parse the input stream.
> Implementing such a method in James shouldn't be too difficult since org.apache.james.core.MimeMessageSource already has a method to retrieve the raw input stream.
> setMessage() would also have to be accompanied by a method to overwrite the raw content of the message. Preferably this method could return an output stream where the raw data can be written to.
> Example code snippet of desired use case:
> class MyMailet {
>   public void service(Mail mail) {
>     org.apache.james.mime4j.message.Message message = new Message(mail.getRawInputStream());
>     message = manipulateMessage(message);
>     message.writeTo(mail.getRawOutputStream(), MessageUtils.LENIENT);
>   }
> }

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.