On Dec 20, 2007 2:37 PM, James.Strachan <[EMAIL PROTECTED]> wrote:
> robert burrell donkin-2 wrote:
> > On Dec 12, 2007 5:33 PM, Bernd Fondermann <[EMAIL PROTECTED]> wrote:
> >> James.Strachan wrote:
> >> > James.Strachan wrote:
> >> > I'd be happy to hack up a Camel JAMES/Mailet component so you could use
> >> > Camel routes to consume from JAMES Mailets if folks think it'd be
> >> useful.
> >>
> >> +1
> >
> > +1
> >
> > incoming messaging via SMTP would be cool
> >
> > but noel's right that the substantiation question is how to handle the
> > message conversion from an incoming mail containing a mail message
> > plus envelope into a message suitable for routing
> >
> > how does camel handle routing messages via email at the moment?
> >
>
> So Camel has a simple abstract Message API based on an Exchange
> http://activemq.apache.org/camel/maven/camel-core/apidocs/org/apache/camel/Exchange.html
>
> which has usually an IN Message and maybe an OUT Message (but there's
> support for various Message Exchange Patterns etc).
> http://activemq.apache.org/camel/maven/camel-core/apidocs/org/apache/camel/Message.html
>
> so its a pretty simple messaging model that maps well to email, JMS, JBI,
> HTTP, files and so forth.

ok

> Then there's a handy type conversion mechanism so you can easily convert
> headers and bodies of messages between different types. So for example a
> plain text email will automatically turn itself into a JMS TextMessage, a
> MINA text based encoding by default.
> http://activemq.apache.org/camel/type-converter.html

sounds like the best approach to integration would be to just deliver
the raw message to camel and let the converter sort it out

with the ActiveMQ experiment, message transformation code is required
in the integration code.  so integrating with camel probably makes
more sense.

> There's also support for explicit data format marshalling/unmarshalling for
> things like Java serialization or JAXB2 encoding or whatnot...
> http://activemq.apache.org/camel/data-format.html
>
> Which we might want to add support for MIME encoding to that; so it'd be
> easy to transform a MIME encoded message to something or whatever. Otherwise
> a MIME encoded body from a email would just be kept as a byte buffer when
> sent to JMS via a BytesMessage or HTTP as the content etc.

yeh

transfer encoding is one of the aspects that makes email interesting.
a message routed over SMTP may need to be transfer encoding for
transmission. i'm not sure whether the consumer should really need to
understand how to decode the message.

- robert

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to