On 8/23/07, James Strachan <[EMAIL PROTECTED]> wrote:
> > I haven't looked at Camel converters, but would you consider adding a
> > contentType and contentEncoding mimicing the headers of HTTP & SIP.
> > The endpoint can then use the type and encoding to determine how to
> > handle the content.
>
> Incidentally thats come up recently in Camel too; the type converter
> stuff is so useful, folks wanna use it for many different things when
> the Java class/interface is not enough to specify a conversion. e.g.
> convert to Java Object using JAXB2 versus serialization versus SOAP
> encoding
>
> I guess this is no longer type conversion, but more content conversion
> - so maybe a separate API is required. But certainly folks wanna be
> able to do things like
>
> // specify the required Java type and content type
> InputStream in = message.getBody(InputStream.class, "application/xml");
>
> But am wondering if for things like content type / content encoding
> stuff we need a separate kind of mechanism than the Java type
> conversion stuff; or if we could just extend the model to include
> content type as well?
I view type conversion (e.g., java.io.File to org.xml.sax.InputSource)
as being very different than content conversion (e.g., EDI to SOAP).
But I do see that sometimes there is some overlap between these two
concepts. Is it a good idea to lump these two together in the same API
when the business purpose is distinctly different?
Bruce
--
perl -e 'print unpack("u30","D0G)[EMAIL
PROTECTED]&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*"
);'
Apache ActiveMQ - http://activemq.org/
Apache ServiceMix - http://servicemix.org/
Apache Geronimo - http://geronimo.apache.org/
Castor - http://castor.org/
