[
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.
