camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Antoine Toulme <anto...@lunar-ocean.com>
Subject Re: data format for MIME-Multipart
Date Fri, 30 Oct 2015 06:28:23 GMT
Hi Stephan,

I am not a committer, I’d say you want to use a separate component since data formats are
all separate projects.

You can start the ball rolling by opening a pull request. I’d be happy to comment and provide
feedback.

If that can help, I contributed a new data format not long ago. You can maybe take after it?
I hope it helps.

https://github.com/apache/camel/pull/631 <https://github.com/apache/camel/pull/631>


> On Oct 29, 2015, at 11:20 PM, Siano, Stephan <stephan.siano@sap.com> wrote:
> 
> Hi,
> 
> Any feedback on this? Do you think I should contribute this into camel-mail, into a new
component or not at all?
> 
> Best regards
> Stephan
> 
> -----Original Message-----
> From: Siano, Stephan [mailto:stephan.siano@sap.com] 
> Sent: Montag, 26. Oktober 2015 14:51
> To: dev@camel.apache.org
> Subject: data format for MIME-Multipart
> 
> Hi,
> 
> I have written a data format that can convert a Camel message with attachments into a
Camel message having a MIME-Multipart message as message body (and no attachments). The use
case for this is to enable the user to send attachments over endpoints that do not directly
support attachments, either as special protocol implementation (e.g. send a MIME-multipart
over an HTTP endpoint) or as a kind of tunneling solution (e.g. because camel-jms does not
support attachments but by marshalling the message with attachments into a MIME-Multipart,
sending that to a JMS queue, Receiving the message from the JMS queue and unmarshalling it
again (into a message body with attachments).
> 
> Do you think this data format is worth contributing?
> 
> I would propose to contribute it to camel-mail even though it is not exactly mail related.
However I use javamail as a dependency, so the data format shares all dependencies with the
camel-mail component. Do you think this is ok, or should I create a new component for it?
> 
> Best regards
> Stephan


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message