Sounds like a good idea to me. A few remarks though: * also take a look at IPF (Open eHealth Integration platform, http://openehealth.org/display/ipf2/Home), which provides a broad platform for eHealth-related integration. There are classes (particularly see https://github.com/krasserm/ipf/tree/master/platform-camel/ihe/mllp/src/main/java/org/openehealth/ipf/platform/camel/ihe/mllp/core) that do the same thing, although extending it much further, e.g. including straight-forward support for TLS, message fragmentation, etc. * What's the plan regarding Mina2? I updated the HL7MLLPCodec on my machine, but I'm not sure if camel-mina2 is already mature enough. I currently see no possibility of a choice (e.g. two variants of the MLLP Codec for Mina1 and Mina2) in camel-hl7 - and speaking of choice, how desirable is a MLLP Codec for camel-netty?
* and finally, the most general and maybe delicate question - being one of the few HAPI committers (and following Camel as of version 1.6) I would be interested in the general strategy of Camel regarding domain-specific components (such as hl7, quickfix and the like). Would you (and/or FuseSource) continue to maintain and support them, or mostly rely on contributions, or would you rather prefer to see dependencies reversed (e.g. HAPI providing a Camel-HL7 component). Absolutely no offense meant here - just evaluating possibilities. regards Christian -- View this message in context: http://camel.465427.n5.nabble.com/Suggest-Add-a-camel-mllp-component-into-the-incubator-tp5711304p5713359.html Sent from the Camel - Users mailing list archive at Nabble.com.
